Application Development Platform and Software Development Kits that Provide Comprehensive Machine Learning Services

ABSTRACT

The present disclosure provides an application development platform and associated software development kits (“SDKs”) that provide comprehensive services for generation, deployment, and management of machine-learned models used by computer applications such as, for example, mobile applications executed by a mobile computing device. In particular, the application development platform and SDKs can provide or otherwise leverage a unified, cross-platform application programming interface (“API”) that enables access to all of the different machine learning services needed for full machine learning functionality within the application. In such fashion, developers can have access to a single SDK for all machine learning services.

PRIORITY CLAIM

The present application claims priority to and the benefit of U.S. Provisional Application 62/667,959 having a filing date of May 7, 2018, which is incorporated by reference herein in its entirety.

FIELD

The present disclosure relates generally to systems for developing and managing computer applications. More particularly, the present disclosure relates to an application development platform and associated software development kits (“SDKs”) that provide comprehensive services for generation, deployment, and management of machine-learned models used by computer applications such as, for example, mobile applications executed by a mobile computing device.

SUMMARY

Aspects and advantages of embodiments of the present disclosure will be set forth in part in the following description, or can be learned from the description, or can be learned through practice of the embodiments.

One example aspect of the present disclosure is directed to a mobile computing device. The mobile computing device includes one or more processors and one or more non-transitory computer-readable media that collectively store: a computer application; and a machine intelligence software development kit. The machine intelligence software development kit is configured to store one or more machine-learned models and a machine learning library. The machine intelligence software development kit is configured to communicate with the computer application using an application programming interface to receive input data from the computer application. The machine intelligence software development kit is configured to implement the one or more machine-learned models and machine learning library on-device to produce an inference based at least in part on the input data. The machine intelligence software development kit is configured to communicate with the computer application using the application programming interface to provide the inference to the computer application.

Other aspects of the present disclosure are directed to various systems, apparatuses, non-transitory computer-readable media, user interfaces, and electronic devices.

These and other features, aspects, and advantages of various embodiments of the present disclosure will become better understood with reference to the following description and appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate example embodiments of the present disclosure and, together with the description, serve to explain the related principles.

BACKGROUND

A computer application generally refers to a structured collection of computer-readable instructions that, when executed, cause a computing device to perform certain tasks. The computer application can be stored in a memory of the computing device and executed by one or more processors of the computing device.

Example computer applications include mobile applications and web applications. A mobile application generally refers to a computer application that is specifically designed to be executed primarily by a mobile computing device such as a smartphone, tablet, watch, etc. A web application generally refers to a computer application which is executed in part by a web server and interfaces with a computing device (e.g., a mobile computing device) via the Internet. For example, a user can interface with a web application via a mobile web browser executed by a mobile computing device.

Developers of computer applications (e.g., mobile applications and/or web applications) often rely on the use of software development kits (“SDKs”) to develop the application. An SDK can include a set of software development tools that allows the creation of applications for a certain software package, software framework, hardware platform, computer system, operating system, and/or other considerations.

SDKs can often enable the implementation of one or more application programming interfaces (“APIs”) in the form of on-device libraries which enable the application to interface with other computing applications or systems that provide various services to the application. Further, as recent advances in machine learning become more integrated with and commonly used by various applications, machine learning services add yet another aspect for application developers to consider and implement.

However, tools and services (e.g., machine learning services) for mobile applications are highly fragmented. For example, analysis has shown that, on average, a typical mobile application uses approximately 16 different SDKs. This fragmented nature of services is costly at runtime, as the application/device must load and execute numerous different libraries, thereby expending significant processing and memory resources. In addition, application developers are required to digest different documentation, download and integrate each SDK separately, call the different methods of each different SDK, learn the respective consoles of each SDK, and other tasks, greatly complicating the development process.

Furthermore, deep neural networks and other complex machine-learned models are being used in countless applications today. However, their accuracy stems in part from having a large number of parameters which incur a high compute overhead. It would be beneficial if these models could be run (and their accuracy benefits received) on mobile and other resource-constrained devices such as smart devices.

While running these models on mobile devices would be great for multiple reasons (e.g., faster interaction between the user and the application, no need for internet connectivity, data does not need to be sent to the cloud, etc.), there are quite a few challenges. In particular, complex models often require significant network bandwidth to transmit, memory resources to store, and processing resources to run. As such, in certain scenarios, complex models may be too large or resource-intensive to run on a resource-constrained device.

BRIEF DESCRIPTION OF THE DRAWINGS

Detailed discussion of embodiments directed to one of ordinary skill in the art is set forth in the specification, which makes reference to the appended figures, in which:

FIG. 1 depicts a block diagram of an example computing system according to example embodiments of the present disclosure.

FIG. 2 depicts a stack diagram of an example computing system according to example embodiments of the present disclosure.

FIG. 3 depicts a functional diagram of an example console according to example embodiments of the present disclosure.

FIG. 4 depicts a workflow diagram of an example computing system according to example embodiments of the present disclosure.

FIG. 5 depicts a workflow diagram of an example computing system according to example embodiments of the present disclosure.

FIG. 6 depicts a flow chart diagram of an example process for generating and deploying machine-learned models according to example embodiments of the present disclosure.

FIG. 7 depicts a workflow diagram of an example process for generating and deploying machine-learned models according to example embodiments of the present disclosure.

FIG. 8 depicts a swim lane diagram of an example process to upload machine-learned models for distribution according to example embodiments of the present disclosure.

FIG. 9 depicts a swim lane diagram of an example process to download machine-learned models according to example embodiments of the present disclosure.

FIG. 10 depicts a block diagram of an example computing system that includes a fat SDK according to example embodiments of the present disclosure.

FIG. 11 depicts a block diagram of an example computing system that includes a thin SDK according to example embodiments of the present disclosure.

FIG. 12 depicts a block diagram of an example computing system that includes mobile vision models as part of an updatable first party support application according to example embodiments of the present disclosure.

FIG. 13 depicts a block diagram of an example computing system that includes mobile vision, text, and speech models as part of an updatable first party support application according to example embodiments of the present disclosure.

FIG. 14 depicts a block diagram of an example computing system that includes an updatable first party support application that performs both runtime and training according to example embodiments of the present disclosure.

FIG. 15 depicts a workflow diagram for an example training pipeline according to example embodiments of the present disclosure.

FIG. 16A depicts a graphical diagram of an example joint training scheme according to example embodiments of the present disclosure.

FIG. 16B depicts a graphical diagram of the example joint training scheme used to train multiple student models according to example aspects of the present disclosure.

FIG. 17 depicts an example user interface according to example embodiments of the present disclosure.

FIG. 18 depicts an example user interface according to example embodiments of the present disclosure.

DETAILED DESCRIPTION Overview

Generally, the present disclosure is directed to an application development platform and associated software development kits (“SDKs”) that provide comprehensive services for generation, deployment, and management of machine-learned models used by computer applications such as, for example, mobile applications executed by a mobile computing device. In particular, the application development platform and SDKs can provide or otherwise leverage a unified, cross-platform application programming interface (“API”) that enables access to all of the different machine learning services needed for full machine learning functionality within the application. In such fashion, developers can have access to a single SDK for all machine learning services. Thus, developers will have a single set of docs, a common way of getting machine learning products, a single console to visit, and a single initialization call to serve all of the application's different machine learning needs.

According to one aspect of the present disclosure, the application development platform can enable a developer to generate custom models for their application. In one example, the developer can upload or otherwise provide access to training data and can then use the application development platform to create and train a machine-learned model for use in conjunction with their application. In another example, the developer can upload a pre-trained model to the platform. In yet another example, the developer can select a pre-trained model from a set of available pre-trained models that are made available to the users of the platform. The developer can use the pre-trained model as-is or can retrain the model on additional training data.

Further, after training of the model or, in some implementations, as part of the training process itself, the application development platform can enable the developer to compress and/or convert the models to optimize the models for use by a resource-constrained device (e.g., mobile or embedded device) or in a resource-constrained environment. For example, compressing the model can include performing quantization (e.g., scalar quantization, vector quantization/weight sharing, product quantization, etc.), pruning (e.g., pruning by values, L1 regularization, etc.), low rank representation (e.g., circulatent matrix, Kronecker structures, SVD decompositions, etc.), distillation, and/or other compression techniques, including a novel learning technique described further herein that directly learns memory- and compute-efficient (e.g., small-sized and fast) machine-learned models that can be directly used for inference on edge devices such as mobile phones, devices able to be worn, and Internet of Things devices. Thus, various compression tools can optionally be accessed and used to compress a learned or uploaded model.

More particularly, aspects of the present disclosure are directed to an end-to-end compression learning framework that allows compression of an input model (e.g., a large pre-trained model) through a learning process in which a compact model is learned based on the input model. The compact model can be a ready-to-use on-device model that is smaller in size, more memory-efficient, more power-efficient and faster at inference with minimal loss in accuracy. Additional state-of-the-art techniques for compressing machine-learned models can also be used in combination with the compression learning framework.

Converting the model can include converting the model from a standard version into a mobile-optimized version that is compatible with a lightweight machine learning library designed specifically for mobile and embedded devices. In one example, the platform can use a conversion tool known as TensorFlow Lite Optimizing Converter (“TOCO”) to convert a standard TensorFlow graph of a model into a TensorFlow Lite graph, where TensorFlow Lite is a lightweight machine learning library designed for mobile applications. Thus, various conversion tools can optionally be accessed and used to convert a learned or uploaded model into a mobile-optimized version.

The compression/conversion service can also provide various tools and dashboards to enable the developer to explore and control compression options. For example, the tools can show tradeoffs with quality, enable parameter tuning, and/or other controls that allow granular control of the compression outcome. For example, the developer can use the compression service to generate multiple models with different sizes and corresponding tradeoffs. These multiple models can be used as part of a model targeting scheme, as described further below.

According to another aspect of the present disclosure, as mentioned above, the present disclosure provides an end-to-end framework and cloud-based solution and API for learning memory- and compute-efficient (i.e., small-sized and fast) machine-learned models that can be directly used for inference on resource-constrained devices. In particular, in some implementations, the end-to-end learning framework can be provided as part or a feature of the application development platform described herein. Thus, the application development platform can employ the end-to-end framework to train a compact machine-learned model that is useful for different problem domains in which a more a complex machine-learned model is typically used.

When the end-to-end learning framework is combined with or provided as a feature of the application development platform, the result is an end-to-end cloud-packaged solution that enables developers to easily train their own high-quality custom on-device models. This enables developers to directly learn models optimized for size and quality using advanced machine learning technology starting from raw training data or their pretrained model checkpoints (if available). However, the end-to-end learning framework can also be used outside the context of or separate from the application development platform. Thus, although the present disclosure focuses on use of the end-to-end framework in the context of the application development platform, the end-to-end framework is not limited to use within such context.

Thus, the end-to-end framework can enable direct learning of compact custom models, which is different from (but optionally complementary to) other techniques (e.g., quantization) which aim to compress model weights post-training or perform model format conversion (e.g., TOCO). The trained compact model can perform in situations involving limited computing power and limited memory for different problem domains that require high computing power and high memory for a complex model. As such, the trained compact machine-learned model can perform prediction tasks on a computing device in situations involving limited computing power and limited memory.

The end-to-end framework can: learn from various input sources; cover a wide range of prediction tasks; support a plurality of use-cases; be powerful in terms of learnable machine-learned models and/or architectures supported; be compatible with infrastructure requirements, such as TensorFlow Lite integration, fast training (e.g., through the use of distributed techniques), access by internal and/or external users (e.g., developers), and platform integration for SDK; and be easily used.

In some implementations, a compact machine-learned model describes a machine-learned model that uses only relatively limited computing power and limited memory, such as a memory- and compute-efficient machine-learned model, or any other suitable machine-learned model with small size and fast computing time. A complex machine-learned model describes a machine-learned model that uses relatively higher computing power and higher memory to predict complex tasks, such as feed-forward neural networks, long short-term memory recurrent neural networks, or other machine-learned models with high computational cost. In some particular scenarios, a complex machined-learned model may be too large or too cumbersome to effectively run on a resource-constrained computing device.

According to one aspect of the present disclosure, the application development platform can be flexible and can enable learning from various inputs and generation of models that predict a wide range of prediction tasks. That is, the end-to-end framework provided by the platform can receive various inputs from a developer and can train a compact model based on and/or which satisfies such inputs.

In some implementations, an input for training the compact machine-learned model can be data, one or more input functions, and/or one or more parameters defining the compact machine-learned model for training the compact machine-learned model. Examples of an input can include labeled data for supervised machine-learned compact model, unlabeled data for compact semi-supervised machine-learned model, pre-trained machine-learned model (which may be used as a trainer model), a desired inference speed, and/or a desired model size.

One example input source is labeled data. For example, the platform can train compact models directly from raw data provided in a format typical for a machine learning library (e.g., tensorflow.Example). The platform can also work with unlabeled data in semi-supervised settings. Another example input source is a pre-trained model. For example, the pre-trained machine-learned model can be larger in size than the compact machine-learned model that will be learned. In one example, the pre-trained model can be a checkpoint from a production model deployed for cloud-based inference.

Inference speed can be a flexible parameter in the input space (e.g., definable by the developer). The inference speed describes a computational efficiency of the compact machine-learned model to run on a wide range of computing devices (e.g., mobile devices, devices able to be worn, embedded devices, etc.). The inference speed can be used to guide a choice of architecture for the compact machine-learned model. The inference speed can depend on compute resources available on a specific device.

Model size can be a flexible parameter in the input space (e.g., definable by the developer). The model size describes a size of the compact machine-learned model after the training process completes. In some implementations, the application development platform can jointly train multiple compact machine-learned models at different sizes (e.g., small: <1-2 million (M), medium: 5-10M, large: >10M) and can make the trained compact machine-learned models available to developers/users so that the users can select a custom-sized model for a particular use-case. In some implementations, the application development platform can train the compact machine-learned model to have a differentiable architecture (e.g., either from a family of efficient architecture skeletons or a set of efficient software operations (ops) such as projections, depth-first convolutions, etc.), rather than pre-specifying a model specification.

In some implementations, the input can further include an indication of the type or class of input. Example types of input include text, image, video, multimodal (text combined with image), sensor signals from a computing device (e.g., the device on which the model will be deployed), or some combination thereof.

In some implementations, the input can further include an indication of the prediction task that will be performed by the trained model. Example prediction tasks performed by the compact machine-learned model (and provided as input) can include a classification (e.g., the number of classes can range from small (e.g., binary or 10-100) to large output spaces (e.g., 10k or 1M categories)); a regression; or a structured prediction (e.g., sequences).

According to another aspect of the present disclosure, the application development platform can improve prediction accuracy of the compact machine-learned model by jointly training the compact machine-learned model with a trainer model, which may in some instances, be a pre-trained machine-learned model. A pre-trained machine-learned model can be a machine-learned model that is previously trained by the application development platform or by external systems. The pre-trained machine-learned model can be larger in size than the compact machine-learned model, such as a checkpoint from a production model deployed on the cloud. In some implementations, the pre-trained machine-learned model can be a complex model that needs higher computing power and higher memory than the compact machine-learned model.

The joint training enables the compact machine-learned model to learn from (and/or with) the trainer model, thereby improving the prediction accuracy of the compact machine-learned model. Thus, the joint training can follow a teacher-student joint training architecture.

Thus, in some implementations, the application development platform can include and implement a training pipeline to train a compact machine-learned model. The training pipeline can train the compact machine-learned model individually and/or jointly train the compact machine-learned model with a trainer model (e.g., pre-trained model). Thus, the trainer or teacher model can be fixed or can be jointly optimized with the student model.

The trainer or teacher model can be any type of model, including, as examples, feed forward neural networks, recurrent neural networks (e.g., long short-term memory networks), quasi-RNNs, convolutional neural networks, ProjectionNets (e.g., dense and sparse versions), BiLSTM (bi-directional LSTMs), depth-separable ConvNets, MobileNets, ProjectionCNN, NASNets, Inception (e.g., Inception v3), ResNet, and/or other types of machine-learned models. The compact or student model can be any type of model but is typically lighter weight than the trainer model. Example student models include feed forward neural networks, recurrent neural networks (e.g., long short-term memory networks), quasi-RNNs, convolutional neural networks, ProjectionNets (e.g., dense and sparse versions), BiLSTM (bi-directional LSTMs), depth-separable ConvNets, MobileNets, ProjectionCNN, NASNets, Inception (e.g., Inception v3), ResNet, and/or other types of machine-learned models.

In some implementations, the training pipeline can receive one or more inputs from users. For instance, the training pipeline can receive training data along with corresponding input functions for training and input functions for evaluation. The training pipeline can create a schema to specify how one or more trainings for the compact machine-learned model will proceed. The training pipeline can further provide an experiment (e.g., tf.Experiment) based API to construct a network. The training pipeline can invoke the training (e.g., starting the training in a wrapper code and/or training infra).

The training pipeline can train the compact model until a desired number of steps is achieved. The training pipeline can export the trained compact machine-learned model in a specific format (e.g., TF-Lite format). In some implementations, the trained compact machine-learned model can be then used to run on a computing device (e.g., on-device).

In some implementations, the created schema can include several fields, such as experiment name, features (e.g., name of a field, type of a feature, one or more dimensions of a feature, etc.), hyperparameters (e.g., learning rate, number of steps, optimizer, activation layer, loss weight for a pre-trained model, loss weight for the compact model, cross loss weight, etc.), a model specification of the compact model that contains multiple fields to construct the compact model, a model specification of the pre-trained model that contains multiple fields to construct the pre-trained model.

In some implementations, the training pipelines can remove or add fields into a model specification based on ongoing development, and/or new use cases. In some implementations, the training pipeline can validate the schema to make sure that the training pipeline behaves as expected. Before starting the pipeline, each of the fields in the schema is validated. Fields in the model specification can be also validated by a validation method of a respective model class.

In some implementations, the training pipeline can jointly train a compact machine-learned model with a pre-trained machine-learned model. For instance, the training pipeline can receive the pre-trained machine-learned model, the compact machine-learned model, training data, and/or corresponding input functions. The training pipeline can create a schema for specifying how the training will proceed. The training pipeline can provide an experiment-based API to specify the joint training. The training pipeline can invoke joint training.

The training pipeline can jointly train the compact machine-learned model with the pre-trained machine-learned model until a joint training loss function indicates that a difference between an output of the compact machine-learned model and an expected output is less than a threshold value. The training pipeline can extract and export the trained compact machine-learned model in a specific format.

In some implementations, the training pipeline can implement and/or store one or more common machine-learned models (e.g., feed forward networks, projection networks, quasi-recurrent neural networks, convolutional neural network, long short-term memory networks, etc.) for joint training. As such, instead of inputting the pre-trained machine-learned model or a custom compact model specification, users can select a model that is stored and/or implemented in the training pipeline and can input the selection into the training pipeline. In response to the user's selection, the training pipeline can create a schema to specify how the training will proceed with the selected model(s).

In some implementations, the training pipeline can include one or more debugging metrics such as various losses, accuracy, confusion matrices for pre-trained machine-learned models and compact machine-learned models. In some implementations, these added metrics are apart from other metrics (e.g., metrics along with Tensorboard integration). In some implementations, the training pipeline can include example implementations of a wrapper for using tf.Estimator API and other plugins. In some implementations, the training pipelines can include integration with TOCO to export the trained compact machine-learned model to TF-Lite format.

Example uses of compact models generated via the end-to-end framework include: test applications (e.g., MNIST, CIFAR10/CIFARI00), smart reply, handwriting recognition, wear health (e.g., heart rate prediction), wear notification (e.g., content-based classification), text classification/ranking, emotion detection, sensitive content detection, gesture recognition, image classification, and/or multimodal learning (e.g., photo reply).

According to another aspect of the present disclosure, the application development platform can enable and perform machine-learned model management. For example, after training, compression, and/or conversion of the model, the developer can use the platform to store the model to a cloud storage database. From the cloud storage database, the developer can use the platform to cause the model to be downloaded to devices that have the developer's application already stored thereon. The platform can also enable the developer to perform various other management functions, including, for example, versioning, compatibility, A/B testing, download management, and/or the like.

Thus, the platform can provide and perform a complete, start-to-finish model generation workflow, which can include the platform: receiving an uploaded model or learning a new model based on uploaded training data; automatically compressing the model with benchmarks; converting the model to a mobile-optimized format; and hosting the model for on-device download and usage.

According to another aspect of the present disclosure, in some implementations, the custom, third party models can be included in a machine intelligence SDK that forms a portion of the application and communicates with the application using a platform APL For example, the machine intelligence SDK can be included in a package of the application that is downloaded from an application marketplace. Thus, the custom models can be downloaded by the device and can run on-device to provide inferences to the application.

Thus, in some implementations, the application development platform can supports so-called “fat” SDKs, where the service runs in the application process. This architecture can provides security and privacy benefits for third party data and models. Alternatively, as will be described further below, the platform can allow exposing via an API existing on-device models that are not included in the application.

Aspects of the present disclosure also enable out-of-band model updating, where an updated version of the model can be downloaded to the machine intelligence SDK on the device without requiring a re-installation of the application as a whole. In other implementations, the models can be downloaded at runtime and inserted into the machine intelligence SDK. Separating download of the models from download of the application as a whole or from download of a more general application update can assist in reducing the size of the application package download or application update download, thereby reducing waiting times and application down time.

According to another aspect, the application development platform can enable the application to leverage first party models that are provided as a feature of the platform. In some implementations, the first party models can be included in the machine intelligence SDK as described above. Alternatively or additionally, the first party models can be included in a first party support application that is separate from the developer's application. In yet other implementations, first and/or third party models can be maintained in the cloud and inferences can be obtained from the models over a network via an API.

Thus, the application development platform can enable an application to access (e.g., to call for inference via an API) both first party models (e.g., general-use models that are provided/maintained by the platform operator) and custom, third party models (e.g., application-specific models that are associated with the specific application developer). In particular, these models can be contained and dynamically updated within a machine intelligence SDK that is included within the application, such that the models provide on-device inference. For example, the first party models can be accessed through the use of a base API while the third party models can be accessed via a custom API.

More particularly, as used herein, the designation “first party” refers to system components (e.g., machine-learned models) that are generally generated, maintained, and/or controlled by the same entity that that operates the platform-at-large. Thus, as a feature of the application development platform, the entity can also provide access to one or more first party models. These first party models can be general-use machine-learned models that provide high quality performance at commonly required tasks such as speech analysis (e.g., natural language processing, voice recognition, and/or the like), text analysis, image analysis (e.g., object detection, barcode/QR code reading, optical character recognition, and/or other tasks which may be categorized as “mobile vision”), and/or the like. Another example first party machine-learned model may be a smart reply model (e.g., accessed via an API) that, in response to an input set of text, predicts possible textual replies with which the user may wish to respond.

In contrast, the designation “third party” refers to system components (e.g., machine-learned models) that are produced by an entity other than the entity that operates the platform-at-large. In one example, third party models may be generated and/or controlled by the application developer. For example, the application developer can use aspects of the platform to generate and deploy their own custom machine-learned models. In another example, third party models may be generated and/or controlled by an additional entity other than the application developer. For example, the application developer can use the application development platform to receive models from such additional entity.

According to another aspect of the present disclosure, the machine intelligence SDK can further include a dedicated machine learning library that can be implemented by the application to run and/or train the models included in the machine intelligence SDK on-device. In some implementations, this machine learning library can be a lightweight library designed for mobile applications (e.g., TensorFlow Lite). Alternatively or additionally, a copy of the same or different machine learning library can also be included in a first party support application. Models included within the first party support application can be run and/or trained on-device by the first party support application using such copy of the machine learning library.

In some implementations, the machine intelligence SDK included within the developer's application and/or the first party application can perform on-device data logging. This on-device logging can support on-device inference and/or training. With respect to on-device training, in some implementations, the machine intelligence SDK can perform validation of training data on-device as part of the logging process. For example, the SDK can detect and exclude anomalies from being logged into the training data. The on-device training can enable personalization of models based on user-specific data. In further implementations, the on-device training can enable participation of the device in a federated learning scheme.

Thus, aspects of the present disclosure are directed to device-wide model training management (e.g. scheduling, storage, etc.). In some implementations, batch training can be performed according to scheduling rules. The scheduling rules can be default and/or customized according to a developer-specified configuration. As one example, training can occur once per day, at night, and when the device is not actively in use, actively being charged, and connected to a network.

The logging can also enable on-device performance monitoring. For example, in some implementations, the machine intelligence SDK can further perform on-device trained model quality validation (e.g., performance monitoring). These quality statistics can be relayed to the developer via a dashboard offered by the application development platform.

In addition or alternatively to on-device inference and/or training, the platform can also enable the application to receive inference and/or training services via the cloud. In one example, the developer may be enabled to specify (e.g., for a subset of devices and/or models) whether inference and/or training occurs on-device or via a cloud service. Both of these options can be supported by a single machine intelligence SDK, providing dynamically-controllable flexibility around the location of inference/training. In some implementations, different APIs or parameters can be used to support each of the two options. In some implementations, the developer can specify rules that handle when inference and/or training should occur on-device or in the cloud and the machine intelligence SDK can implement these rules. For example, use of rules can enable the platform to automatically handle transition/balancing between on-device and cloud services (e.g., to implement a workload balancing scheme). In some implementations, whether inference and/or training occurs on-device or in the cloud can be transparent to the device user.

In addition to dynamic model download and deployment, the application development platform can enable further advanced machine learning services, including, for example, versioning, compatibility, A/B testing, download management, and/or various other management functions. As one example, the application development platform can enable a developer to perform or allow automatic model targeting. For example, different versions of machine-learned models can be distributed to different types of devices. In one example, a larger, more complex model can be distributed to devices with more advanced computing capabilities (e.g., larger memory size, faster processor, etc.) while a smaller, less complex model can be distributed to devices with less advanced computing capabilities. In other examples, different model versions can be downloaded to different devices depending on the geolocation of the device (e.g., English language model for United Kingdom versus French language model for France), characteristics of the user of the device (e.g., paid membership versus free trial), and/or other device and/or user attributes. For example, the developer can specify rules to govern the model targeting and the platform can implement the rules. Thus, the platform can enable an optimal version of a model to be sent (e.g., dynamically downloaded) to each different device.

As another example, the application development platform can provide monitoring of and dashboards that display evaluations of models and system health (i.e., a model evaluation service). For example, the platform can provide analytics on model usage, performance, download status, and/or other measures. Statistics of performance can include descriptions of accuracy, accuracy under curve, precision vs recall, confusion matrix, speed (e.g., #FLOPs, milliseconds per inference), and model size (e.g., before and after compression). The analytics can be used by the developer to make decisions regarding model retraining and compression.

The platform can also provide dashboards that allow the developer to explore system status and health such as model compatibility, availability of stored models, download status, and/or the like. Furthermore, the platform can enable the developer and the devices to ensure (and resolve if needed) backward and forward compatibility of model updates.

As another example, the application development platform can enable a developer to perform A/B experimentation. For example, the developer can enable two models to be used for different traffic or different sets of devices. The platform can collect the resulting data and can provide analytics that enable the developer to explore the performance statistics and outcomes.

The systems and methods of the present disclosure provide a number of technical effects and benefits. As one example technical effect, the application development platform and associated SDKs enable the on-device use of mobile-optimized machine-learned models. These mobile-optimized models provide the following benefits: smaller model size; less memory usage; faster computation; and more efficient power utilization, all with competitive model performance. Further, absent the platform tools described herein which enable easy mobile-optimized model generation and deployment, application developers may choose to perform inference in the cloud. Thus, by enabling on-device usage, the systems and methods of the present disclosure obviate the need for cloud inference calls, thereby reducing network traffic. Further, by enabling on-device training, the systems and methods of the present disclosure can lead to improved model performance including, for example, personalized models and/or models that have been produced through federated learning.

As another example technical effect and benefit, the systems and methods of the present disclosure enable out-of-band model updating, where an updated version of the model can be dynamically downloaded to the machine intelligence SDK on the device without requiring a re-installation of the application as a whole. Separating download of the models from download of the application as a whole or from download of a more general application update can assist in reducing the size of the application package download or application update download, thereby reducing waiting times and application down time. Further, updated models can be distributed in a less intrusive manner and with smaller download sizes.

With reference now to the Figures, example embodiments of the present disclosure will be discussed in further detail.

Example Computing Systems

FIG. 1 depicts a block diagram of an example computing system according to example embodiments of the present disclosure. The example computing system includes developer computing devices 130, an application development computing system 102, and user computing devices 140 in communication over one or more networks.

The developer computing devices 130 can be any type of computing device including, as examples, laptops, smartphones, desktops, server computing devices, etc. The developer computing devices 130 can include one or more processors and a memory. The developer computing devices 130 can be used by application developers to communicate with and/or control an application development platform 116 implemented by the application development computing system 102. As one example, the developer computing device 130 can include a dedicated computer program or application that is designed to communicate with and/or control the application development platform 116. As another example, the developer computing device 130 can include a browser application that communicates with the application development platform 116. For example, the application development platform 116 can provide services to the developer computing device 130 via the browser application.

The application development computing system 102 can include one or more processors 112 and a memory 114. The one or more processors 112 can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or a plurality of processors that are operatively connected. The memory 114 can include one or more non-transitory computer-readable storage mediums, such as RAM, ROM, EEPROM, EPROM, flash memory devices, magnetic disks, etc., and combinations thereof. The memory 114 can store data 116 and instructions 118 which are executed by the processor 112 to cause the user computing device 102 to perform operations.

In some implementations, the application development computing system 102 includes or is otherwise implemented by one or more server computing devices. In instances in which the application development computing system 102 includes plural server computing devices, such server computing devices can operate according to sequential computing architectures, parallel computing architectures, or some combination thereof.

The application development computing system 102 provides an application development platform 116. The application development platform 116 can provide comprehensive services for generation, deployment, and management of machine-learned models. The application development platform can include a console manager 118, a model manager 120, and a machine learning manager 122.

The console manager 118 can control and/or manage presentation of a console at the developer computing device 130, including, for example, tasks like presenting a console interface, modifying the console interface, receiving user input directed to the console interface, etc. In some implementations, the console manager 118 can be included in an application stored at the developer computing device 130, or can include portions at both the developer computing device 130 and the application development computing system 102.

The model manager 120 can provide various model management services, including, as examples, a model compression service, a model conversion service, a model evaluation service, model hosting/download management services, and/or other model management services including, for example, versioning, compatibility, and/or A/B testing services.

The machine learning manager 122 can provide a number of machine learning services such as, for example, a model training service and/or a training data management service. The machine learning manager 122 can include and use a machine learning library to train models. Example machine learning libraries include the TensorFlow and TensorFlow Lite libraries.

Each of the console manager 118, model manager 120, and machine learning manager 122 includes computer logic utilized to provide desired functionality. Each of the console manager 118, model manager 120, and machine learning manager 122 can be implemented in hardware, firmware, and/or software controlling a general purpose processor. For example, in some implementations, each of the console manager 118, model manager 120, and machine learning manager 122 includes program files stored on a storage device, loaded into a memory and executed by one or more processors. In other implementations, each of the console manager 118, model manager 120, and machine learning manager 122 includes one or more sets of computer-executable instructions that are stored in a tangible computer-readable storage medium such as RAM hard disk or optical or magnetic media.

The application development platform 116 can be communicatively coupled to one or more databases including, for example, a cloud storage database 124 and/or an application data database 126. The application data database 126 can be a globally-distributed relational and/or non-relational database. The databases 124 and 126 can be one database or can be multiple distributed databases.

The application development platform 116 can also communicate with one or more user computing devices 140. Each user computing device 140 can be any type of computing device including desktop computing devices, server computing devices, mobile computing devices (e.g., smartphones, laptops, tablets, device able to be worn, etc.), embedded devices, smart devices, Internet of Things devices, gaming consoles, computing devices in vehicles, and/or any other form of computing device. Each user computing device 140 can include one or more processors (e.g., as described at 112) and a memory (e.g., as described at 114).

In some implementations, a user computing device 140 can include an application 142. For example, the application 142 can have been developed by a developer associated with a developer computing device (e.g., through use of the application development platform 116). The application 142 can include a machine intelligence SDK 144 that is associated with the application development platform. The machine intelligence SDK 144 can include computer-readable instructions that enable the application 142 to interface with the application development platform 116 and/or other system components (e.g., via the use of one or more platform APIs).

According to aspects of the present disclosure, in some implementations, the machine intelligence SDK 144 can include one or more machine-learned models 146 and a machine learning library 148. For example, the models 146 can have been downloaded (e.g., dynamically and out-of-band) from the cloud storage 124 (e.g., according to instructions received from the model manager 120). The machine intelligence SDK 144 can use the machine learning library 148 to run the machine-learned models 146 to produce inferences for the application 142 on the user computing device 140.

In some implementations, the user computing device 140 can also include a first party support application 152. The first party support application 152 can be a standalone application or can be provided as a portion of the operating system of the user computing device 140.

The first party support application 152 can also include a machine intelligence SDK 154 that is associated with the application development platform. The machine intelligence SDK 144 can include computer-readable instructions that enable the application 152 to interface with the application 142 (e.g., the machine intelligence SDK 144), the application development platform 116, and/or other system components (e.g., via the use of one or more platform APIs).

According to aspects of the present disclosure, in some implementations, the machine intelligence SDK 154 can include one or more machine-learned models 156 and a machine learning library 158. For example, the models 158 can have been downloaded (e.g., dynamically and out-of-band) from the cloud storage 124 (e.g., according to instructions received from the model manager 120). The machine intelligence SDK 154 can use the machine learning library 158 to run the machine-learned models 156 to produce inferences for the application 142 on the user computing device 140.

FIG. 2 depicts a stack diagram of an example computing system according to example embodiments of the present disclosure. In particular, FIG. 2 illustrates a console interface that communicates/interacts with the model manager 120, machine learning manager 122, cloud storage database 124, and application data database 126 via one or more platform APIs.

As illustrated, the model manager 120 can provide a model compression service, a model conversion service, a model evaluation service and a model hosting service. The model compression service and/or model conversion service can enable the developer to compress and/or convert the models to optimize the models for use by a mobile device or in the mobile environment. For example, compressing the model can include performing quantization (e.g., scalar quantization, vector quantization/weight sharing, product quantization, etc.), pruning (e.g., pruning by values, L1 regularization, etc.), low rank representation (e.g., circulatent matrix, Kronecker structures, SVD decompositions, etc.), distillation, and/or other compression techniques.

Pruning reduces model size by removing weights or operations from the model that are least useful for predictions, including, for example, low-scoring weights. This can be very effective especially for on-device models involving sparse inputs. For example, certain on-device conversational models can be pruned further to achieve up-to 2× reduction in size with just 25% lower triggering rate while retaining 97% of the original prediction quality.

Quantization techniques can improve inference speed by reducing the number of bits used for model weights and activations. For example, using 8-bit fixed point representation instead of floats can speed up the model inference, reduce power and reduce size by 4×.

Thus, various compression tools can optionally be accessed and used to compress a learned or uploaded model.

Converting the model can include converting the model from a standard version into a mobile-optimized version that is compatible with a lightweight machine learning library designed specifically for mobile and embedded devices. In one example, the platform can use a conversion tool known as TensorFlow Lite Optimizing Converter (“TOCO”) to convert a standard TensorFlow graph of a model into a TensorFlow Lite graph, where TensorFlow Lite is a lightweight machine learning library designed for mobile applications. Thus, various conversion tools can optionally be accessed and used to convert a learned or uploaded model into a mobile-optimized version.

The model evaluation service can provide analytics on model usage, performance (e.g., accuracy, speed, and model size), download status, and/or other measures. The analytics can be used by the developer to make decisions regarding model retraining and compression. The model evaluation service can also provide dashboards that allow the developer to explore system status and health such as model compatibility, availability of stored models, download status, and/or the like. Furthermore, the model evaluation service can enable the developer and the devices to ensure (and resolve if needed) backward and forward compatibility of model updates.

As another example, the model evaluation service can enable a developer to perform A/B experimentation. For example, the developer can enable two models to be used for different traffic or different sets of devices. The platform can collect the resulting data and can provide analytics that enable the developer to explore the performance statistics and outcomes.

The model hosting service can enable models to be downloaded to devices (e.g., devices that have the developer's application stored thereon). The model hosting service can also enable the developer to perform various other management functions, including, for example, versioning, compatibility, download management, model targeting, and/or the like.

The machine learning manager 122 can provide a training data management service. This service can include a training data flow with comprehensive services including data augmentation, data visualization, data label crowdsourcing, etc. Training data augmentation can include data rotation, perturbation, supplementation (e.g., via image searches), etc.

The machine learning manager 122 can provide a model training service. The model training service can perform training and/or re-training of models. For example, standard training techniques can be used to train models based on training data.

In some implementations, the model training service can perform training techniques provided by the present disclosure that result in learning of compute- or memory-efficient models. In particular, in some implementations, the model training service can perform a novel training scheme that enables direct learning of a compact machine-learned model. For example, the model training service can jointly train the compact machine-learned model with a larger, more complex model in a teacher-student training structure that enables the compact machine-learned model to learn from and approximate the more complex machine-learned model.

In some implementations which employ the schemes described herein which enable direct learning of compact models, quantization can be applied during training. That is, the model (e.g., network) learns to optimize the weights and activations in the quantized space using gradients computed via backpropagation. This can be more effective than applying this method post training (e.g., quantizing pre-trained weights just for inference).

Some of the joint training and distillation approaches provided by the present disclosure follow a teacher-student setup where the knowledge of the trainer model is utilized to learn an equivalent compact student model with minimal loss in accuracy. During training, the teacher or trainer model parameters can be held fixed (e.g., as in distillation) or jointly optimized to improve both models simultaneously.

In some implementations, the trainer model can also be jointly trained with multiple student models of different sizes. So instead of providing a single compressed model, the machine learning manager 122 can generate multiple on-device models at different sizes and inference speeds and the developer can select the model that is best suited for their application needs (e.g., provides the most appropriate tradeoff between size and performance). Additionally, jointly training multiple compact models with shared parameters typically takes only slightly more time than training a single large model, but yields multiple compressed/compact models in a single shot that are smaller in size, faster, and have lower cost relative to the more complex model, while still providing good prediction accuracy. These techniques can be combined with other techniques like transfer learning to make the learning/compression process more efficient and scalable to large-scale datasets.

More generally, the machine learning manager 122 can include and implement a training pipeline to train a compact machine-learned model. The training pipeline can train the compact machine-learned model individually and/or jointly train the compact machine-learned model with the pre-trained machine-learned model.

In some implementations, the training pipeline can receive one or more inputs from users. For instance, the training pipeline can receive training data along with corresponding input functions for training and input functions for evaluation. The training pipeline can create a schema to specify how one or more trainings for the compact machine-learned model will proceed. The training pipeline can further provide an experiment (e.g., tf. Experiment) based API to construct a network. The training pipeline can invoke the training (e.g., starting the training in a wrapper code and/or training infra).

The training pipeline can train the compact model until a desired number of steps is achieved. The training pipeline can export the trained compact machine-learned model in a specific format (e.g., TF-Lite format). In some implementations, the trained compact machine-learned model can be then used to run on a computing device (e.g., on-device).

In some implementations, the created schema can include several fields, such as experiment name, features (e.g., name of a field, type of a feature, one or more dimensions of a feature, etc.), hyperparameters (e.g., learning rate, number of steps, optimizer, activation layer, loss weight for a pre-trained model, loss weight for the compact model, cross loss weight, etc.), a model specification of the compact model that contains multiple fields to construct the compact model.

In some implementations, the model specification can include some or all of the following example information:

id: A unique identifier for this model instance.

model_type: (e.g., “feed_forward”, “projection”).

params: A generic dictionary of parameters specific to the model type. For example, projection_size would be a relevant parameter for the projection net, but not for the feedforward nets.

load_checkpoint: If this parameter is set, the model would be loaded from the path which is the value of this parameter.

freeze_model_from_checkpoint: This parameter should only be set to true if load_checkpoint is set. If the value of this parameter is true, gradients would not be backpropagated through this model. This parameter should not be set to true for the pod_model_spec (because it would make no sense to freeze the PoD model, and train the trainer model).

tflite_output_path: If this parameter is set, the pipeline will output this model as a TFLite model (assuming all the ops in the model are supported by TFLite) to the given path.

If both pod_model_spec and trainer_model_spec are defined, then the joint training would proceed. If only pod_model_spec is specified, then the pipeline would train an individual model. Specifying only the trainer_model_spec would be an error.

In some implementations, the training pipeline can remove or add fields into a model specification based on ongoing development, and/or new use cases. In some implementations, the training pipeline can validate the schema to make sure that the training pipeline behaves as expected. Before starting the pipeline, each of the fields in the schema can be validated. Fields in the model specification can be also validated by a validation method of a respective model class.

In some implementations, the training pipeline can implement and/or store one or more common machine-learned models (e.g., feed forward networks, projection networks, quasi-recurrent neural networks, convolutional neural network, long short-term memory networks, etc.) for joint training. As such, instead of inputting the pre-trained machine-learned model or a custom compact model specification, users can select a model that is stored and/or implemented in the training pipeline and can input the selection into the training pipeline. In response to the user's selection, the training pipeline can create a schema to specify how the training will proceed with the selected model(s).

In some implementations, the training pipeline can include one or more debugging metrics such as various losses, accuracy, confusion matrices for pre-trained machine-learned models and compact machine-learned models. In some implementations, these added metrics are apart from other metrics (e.g., metrics along with Tensorboard integration). In some implementations, the training pipeline can include example implementations of a wrapper for using tf.Estimator API and other plugins. In some implementations, the training pipelines can include integration with TOCO to export the trained compact machine-learned model to TF-Lite format.

As one example, FIG. 15 depicts a workflow diagram for an example training pipeline according to example embodiments of the present disclosure. The training pipeline validates a DeepPodSpec for shared fields between models (e.g., a compact model and a pre-trained model). In some implementations, the training pipeline can invoke a validation method (e.g., respective model-type(s)' validate method) for validating a model specification of a corresponding model and the training pipeline can error out if this validation does not succeed.

The training pipeline can create a model_fn to be used by a tf.Estimator object, which does the follow 1) instantiating respective model classes for each model such that the model performs bookkeeping and sanity checks, 2) invoking the forward_pass method (e.g., create_graph) of each model, 3) constructing and retuning loss function and training operations per predictions from each model and a corresponding specification. The training pipeline constructs the tf.Estimator based on outputs from the model_fn and/or other flags related to the input in the specification.

The training pipeline constructs the tfExperiment objects with hooks to call persist for each model. The training pipeline returns the tf.Experiment object.

The training pipeline can further convert Trainer GraphDef to inference GraphDef. The training pipeline can extract PoD model (if trained jointly) into separate network for inference. The training pipeline can convert frozen inference graph to TF-Lite format.

FIG. 16A depicts a graphical diagram of an example joint training scheme according to example embodiments of the present disclosure. In FIG. 16A, a projection network is jointly trained with a trainer network (e.g., feedforward networks, quasi-recurrent neural networks, convolutional neural network, long short-term memory networks, etc.) for learning to mimic predictions made by the trainer network which has far more parameters and hence more predictive capacity. The projection network is provided as one example type of model that can be learned compactly as a student model. Other types of compact models can be jointly learned according to the illustrated training scheme, including, as examples, feed forward neural networks, recurrent neural networks (e.g., long short-term memory networks), quasi-RNNs, convolutional neural networks, ProjectionNets (e.g., dense and sparse versions), BiLSTM (bi-directional LSTMs), depth-separable ConvNets, MobileNets, ProjectionCNN, NASNets, Inception (e.g., Inception v3), ResNet, and/or other types of machine-learned models.

One central aspect of the joint training scheme is a novel objective that jointly trains the two different models—the full trainer model (e.g., using existing architectures like Feed-forward NNs or LSTM RNNs) combined with a simpler student model. For example, the student model can be a projection network that leverages random projections to transform inputs or intermediate representations into bits. Thus, in some implementations, the simpler model can encode lightweight and efficient-to-compute operations in bit space with a low memory footprint.

In some implementations, the two models can be trained jointly using backpropagation, where the student network learns from the teacher network similar to apprenticeship learning. Once trained, the smaller network can be used directly for inference at low memory and computation cost.

The student model can optionally leverage any existing deep network like feed-forward or recursive neural network to teach a lightweight model (e.g., projected model) in a joint optimization setup which is trained end-to-end using backpropagation. In some implementations, projections based on locality sensitive hashing can be used to represent the hidden units for the lightweight network which encodes operations that are extremely efficient to compute during inference.

The framework permits efficient distributed training but can be optimized to produce a neural network model with low memory footprint that can run on devices at low computation cost.

The model size can be parameterized and configurable based on the task or device capacity. The framework is effective in achieving significant reduction in model sizes while providing competitive performance on multiple visual and language classification tasks.

FIG. 16A shows and will be discussed in reference to the framework as applied to train a projection network. However, other model types can be used as the student model other than a projection network.

In some implementations, the trainer network uses {right arrow over (x)}_(i) as an input feature vector to predict a prediction result y_(i). The projection network uses projection functions (

) transform the input feature vector {right arrow over (x)}_(i) to projected feature vector {right arrow over (x)}_(i) ^(p). The projection network uses the projected feature vector to predict a prediction result y_(i) ^(p).

During joint training, a combination of a loss function

_(θ)(.) of the trainer network and a projection loss function

^(P)(.) can be optimized such that the projection network can mimic and learn from the trained network. As shown in FIG. 16, a labeled loss

(.) is also used for the training. The labeled loss

(.) can be based on a comparison between the prediction result y_(i) ^(p) and a ground truth ŷ_(i).

Once learning is completed, the transform functions P(.) and corresponding trained weights W_(p), B^(p) from the projection network are extracted to create a compact model that can be pushed to device. At inference time, the compact model and corresponding operations can be then applied to a given input {right arrow over (x)}_(i) to generate predictions y_(i) ^(p).

More particularly, neural networks are a class of non-linear models that learn a mapping from inputs {right arrow over (x)}_(i) to outputs y_(i), where {right arrow over (x)}_(i) represents an input feature vector or sequence (in the case of recursive neural networks) and y_(i) is an output category for classification tasks, a predicted sequence, a regression value, etc. Typically, these networks consist of multiple layers of hidden units or neurons with connections between a pair of layers. For example, in a fully-connected feed-forward neural network, the number of weighted connections or network parameters that are trained is O(n²), where n is the number of hidden units per layer. Other models can similarly receive the inputs and produce the outputs.

The present disclosure provides a new objective and joint optimization framework for training compact on-device models for inference. FIG. 16A illustrates the Neural Projection Network architecture using a feedforward NN for the trainer network. The coupled networks are jointly trained to optimize a combined loss function:

(θ,p)=λ₁·

_(θ)(.)+λ₂·

^(p)(.)+λ₃·

(.)  Eq. (1)

where

_(θ)(.),

^(p)(.) and

(.) are the loss functions corresponding to the two models as defined below.

$\begin{matrix} {{{{\mathcal{L}_{\theta}\left( . \right)} = {\sum\limits_{i \in N}{\mathcal{D}\left( {{h_{\theta}\left( \overset{\rightarrow}{x_{\iota}} \right)},\overset{\hat{}}{y_{\iota}}} \right)}}}{\mathcal{L}^{p}\left( . \right)} = {\sum\limits_{i \in N}{\mathcal{D}\left( {{h^{p}\left( \overset{\rightarrow}{x_{\iota}} \right)},\ {h_{\theta}\left( \overset{\rightarrow}{x_{\iota}} \right)}} \right)}}}{{\left( . \right)} = {\sum\limits_{i \in N}{\mathcal{D}\left( {{h^{p}\left( \overset{\rightarrow}{x_{\iota}} \right)}_{2}\overset{\hat{}}{y_{\iota}}} \right)}}}} & {{Eqs}.\mspace{14mu}(2)} \end{matrix}$

N indicates the number of training instances in the dataset, {right arrow over (x)}_(i) represents the input feature vector in a feed-forward network or sequence input in an RNN, and ŷ_(i) refers to the ground-truth output classes used for network training. h_(θ)({right arrow over (x)}_(i)) represents a parameterized representation of the hidden units in the trainer network that transforms x to an output prediction y_(i). Similarly, h^(p)({right arrow over (x)}_(i)) represents the projection network parameters that transforms the input to corresponding predictions y_(i) ^(p). Softmax activation can be applied at the last layer of both networks to compute the predictions y_(i) and y_(i) ^(p).

D denotes a distance function that measures the prediction error used in the loss functions. This can be decomposed into three parts-trainer prediction error, projection simulation error and projection prediction error. Reducing the first leads to a better trainer network and decreasing the latter in turn learns a better projection network that is simpler but with approximately equivalent predictive capacity. In practice, cross-entropy can be used for

(.). For the projection Lp in Equation 2, a distillation approach can be followed to optimize

(.) since it has been shown to yield better generalization ability than a model trained on just the labels ŷ_(i). λ₁, λ₂, and λ₃ are hyperparameters that affect the trade-off between these different types of errors. These are tuned on a small heldout development set and, as one example, in experiments were set to λ₁=1.0, λ₂=0.1, λ₃=1.0.

Trainer Network (θ). The trainer model can be a full neural network (feed-forward, RNN or CNN) whose choice can be flexible and depends on the task. FIG. 16A shows a trainer using feed-forward network but this can be swapped with LSTM RNNs or other models such as deep neural networks. For the network shown in the figure, the activations for h_(θ)(.) in layer l_(k+1) can be computed as follows:

$\begin{matrix} {A_{\theta_{l_{k + 1}}} = {\sigma\left( {{W_{\theta_{l_{k + 1}}} \cdot A_{\theta_{l_{k}}}} + B_{\theta_{l_{k + 1}}}} \right)}} & {{Eq}.\mspace{14mu}(3)} \end{matrix}$

where σ is the ReLU activation function applied at each layer except the last and A indicates the computed activation values for hidden units.

The number of weights/bias parameters W_(θ), B_(θ) in this network can be arbitrarily large since this will only be used during the training stage which can be effectively done using high-performance distributed computing with CPUs or GPUs.

Projection Network (p). The projection model is a simple network that encodes a set of efficient to-compute operations which will be performed directly on device for inference. The model itself defines a set of efficient “projection”

({right arrow over (x)}_(i)) that project each input instance {right arrow over (x)}_(i) to a different space Ω

and then performs learning in this space to map it to corresponding outputs y_(i) ^(p). A simplified projection network with few operations is used as illustrated in FIG. 16A. One example projection network is shown. Other structures can be used as well (e.g., additional layers, etc.) The inputs {right arrow over (x)}_(i) are transformed using a series of T projection functions

¹, . . . ,

^(T), which can be then followed by a single layer of activations.

=

¹({right arrow over (x)} ₁), . . . ,

^(T)({right arrow over (x)} ₁)  Eq. (4)

y _(i) ^(p)=softmax(W ^(p) ·

+B ^(p))  Eq. (5)

The projection transformations use pre-computed parameterized functions, i.e., they are not trained during the learning process, and their outputs are concatenated to form the hidden units for subsequent operations. During training, the simpler projection network learns to choose and apply specific projection operations

^(j) (via activations) that are more predictive for a given task. It is possible to stack additional layers connected to the bit-layer in this network to achieve non-linear combinations of projections.

The projection model can be jointly trained with the trainer and learns to mimic predictions made by the full trainer network which has far more parameters and hence more predictive capacity. Once learning is completed, the transform functions

(.) and corresponding trained weights W^(p), B^(p) from the projection network are extracted to create a lightweight model that can be pushed to device. At inference time, the lightweight model and corresponding operations can be then applied to a given input {right arrow over (x)}_(i) to generate predictions y_(i) ^(p).

The choice of the type of projection matrix P as well as representation of the projected space Ω

in the setup has a direct effect on the computation cost and model size. An efficient randomized projection method is leveraged using a modified version of locality sensitive hashing (LSH) to define

(.). In conjunction, a bit representation 1^(d) is used for Ω

i.e., the network's hidden units themselves are represented using projected bit vectors. This yields a drastically lower memory footprint compared to the full network both in terms of number and size of parameters. A few key properties of this approach include:

There is no requirement for committing to a preset vocabulary or feature space unlike typical machine learning methods which resort to smaller vocabulary sizes as a scaling mechanism. For example, LSTM RNN models typically apply pruning and use smaller, fixed-size vocabularies in the input encoding step to reduce model complexity.

The proposed learning method scales efficiently to large data sizes and high dimensional spaces. This is especially useful for natural language applications involving sparse high dimensional feature spaces. For dense feature spaces (e.g., image pixels), existing operations like fully-connected layers (or even convolutions) can be efficiently approximated for prediction without relying on a large number of parameters. Such operations can also be applied in conjunction with the projection functions to yield more complex projection networks while constraining the memory requirements.

Computation of

(x_(i)) can be independent of the training data size.

It can be ensured that

(.) can be efficient to compute on-the-fly for inference on device.

Next, the present disclosure describes the projection method and associated operations in more detail.

Locality Sensitive Projection Network: The projection network described earlier relies on a set of transformation functions

that project the input {right arrow over (x)}_(i) into hidden unit representations Ω

. The projection operations outlined in Equation 4 can be performed using different types of functions. One possibility is to use feature embedding matrices pre-trained using word2vec or similar techniques and model

as an embedding lookup for features in {right arrow over (x)}_(i) followed by an aggregation operation such as vector averaging. However, this requires storing the embedding matrices which incurs additional memory complexity.

Instead, an efficient randomized projection method can be employed for this step. Locality sensitive hashing (LSH) can be used to model the underlying projection operations. LSH is typically used as a dimensionality reduction technique for applications like clustering. A motivation for using LSH within Projection Nets is that it allows one to project similar inputs {right arrow over (x)}_(i) or intermediate network layers into hidden unit vectors that are nearby in metric space. This allows transformation of the inputs and learning of an efficient and compact network representation that is only dependent on the inherent dimensionality (i.e., observed features) of the data rather than the number of instances or the dimensionality of the actual data vector (i.e., overall feature or vocabulary size). This can be achieved with binary hash functions for

.

Theorem 1: For {right arrow over (x)}_(i), {right arrow over (x)}_(j) ∈

^(n) and vectors

_(k) drawn from a spherically symmetric distribution on

^(n) the relation between signs of inner products and the angle

({right arrow over (x)}_(i),{right arrow over (x)}_(j)) between vectors can be expressed as follows:

({right arrow over (x)} _(i) ,{right arrow over (x)} _(j))=πPr{sgn[

{right arrow over (x)} _(i),

_(k)

]≠sgn[

{right arrow over (x)} _(j),

_(k)

]}  Eq. (6)

This property holds from simple geometry, i.e., whenever a row vector from the projection matrix

falls inside the angle between the unit vectors in the directions of {right arrow over (x)}_(i) and {right arrow over (x)}_(j), they will result in opposite signs. Any projection vector that is orthogonal to the plane containing {right arrow over (x)}_(i){right arrow over (x)}_(j) will not have an effect. Since inner products can be used to determine parameter representations that are nearby,

{right arrow over (x)}_(i),{right arrow over (x)}_(j)

=∥{right arrow over (x)}_(i)∥·∥{right arrow over (x)}_(j)∥·cos

({right arrow over (x)}_(i),{right arrow over (x)}_(j)), therefore the network hidden activation unit vectors can be modeled and stored in an efficient manner by using the signature of a vector in terms of its signs.

Computing Projections: Following the above property, binary hashing can be used repeatedly and the projection vectors in

can be applied to transform the input z to a binary hash representation denoted by

_(k)(x)∈{0,1}^(d) where [

_(k)({right arrow over (x)}_(i))]:=sgn[

{right arrow over (x)}_(i),

_(k)

]. This results in a d-bit vector representation, one bit corresponding to each projection row

_(k=1 . . . d).

The projection matrix

can be fixed prior to training and inference. Note explicit storage of the random projection vector

_(k) is not needed since they can be computed on the fly using hash functions rather than invoking a random number generator. In addition, this also permits performance of projection operations that are linear in the observed feature size rather than the overall feature size which can be prohibitively large for high-dimensional data, thereby saving both memory and computation cost. The binary representation can be significant since this results in a significantly compact representation for the projection network parameters that in turn reduces the model size considerably compared to the trainer network.

Note that other techniques like quantization or weight sharing can be stacked on top of this method to provide further gains in terms of memory reduction.

Projection Parameters: In practice, T different projection functions

^(j=1 . . . T) can be employed as shown in FIG. 16A, each resulting in d-bit vector that can be concatenated to form the projected activation units

in Equation 4. T and d vary depending on the projection network parameter configuration specified for

and can be tuned to trade-off between prediction quality and model size.

Training and Inference: The compact bit units can be used to represent the projection network as described earlier. During training, this network learns to move the gradients for points that are nearby to each other in the projected bit space

in the same direction. The direction and magnitude of the gradient can be determined by the trainer network which has access to a larger set of parameters and more complex architecture.

The two networks are trained jointly using backpropagation. Despite the joint optimization objective, training can progress efficiently with stochastic gradient descent with distributed computing on high-performance CPUs or GPUs.

Once trained, the two networks are de-coupled and serve different purposes. The trainer model can be deployed anywhere a standard model can be used. The simpler projection network model weights along with transform functions

(.) are extracted to create a lightweight model that can be pushed to device. This model is used directly “on” device at inference time by applying the same operations in Equations 4, 5 to a new input z and generate predictions y_(i) ^(p).

As an alternative to the bit vector representation Sp, the projection matrix

can instead be used to generate a sparse representation of hidden units in the projection network. Each d-bit block can be encoded as an integer instead of a bit vector. This results in a larger parameter space overall O(T·2^(d)) but can still be beneficial to applications where the actual number of learned parameters can be tiny and inference can be performed via efficient sparse lookup operations.

Any compact machine-learned model can be jointly trained with any trainer model, including, for example, a pre-trained machine-learned model.

In some implementations, the trainer model can also be jointly trained with multiple student models of different sizes. As an example, FIG. 16B depicts a graphical diagram of the example joint training scheme used to train multiple student models according to example aspects of the present disclosure. The multiple student models can be

The compression learning framework described herein has been used in example experimental tests to successfully generate small and fast models with good prediction accuracy suited for mobile applications. For example, on ImageNet task, the compression learning framework was able to generate a model 22× smaller than Inception v3 baseline and 4× smaller than MobileNet vi baseline with just 4.6-7% drop in accuracy. As another example, on CIFAR-10, jointly training multiple models with shared parameters as described herein, takes only 10% more time than training a single large model, but yields 3 compressed models that are up to 94× smaller in size and up to 27× faster with up to 36× lower cost and good prediction quality (90-95% top-1 accuracy).

FIG. 17 depicts an example user interface according to example embodiments of the present disclosure. The user interface can be referred to as a Tensorboard. Once the training starts, users can monitor a training progress on Tensorboard. The Tensorboard has several options (e.g., scalars, graphs, distributions, histograms, and projectors) to present the training progress.

As shown in FIG. 17, “SCALARS” option can be selected to present compact model (also referred to PoD model) accuracy and trainer model accuracy. Several tools to process charts on the right of the user interface are shown on the left of the user interface, such as “Show data download links” to show download links of data associated with the PoD model and/or the trainer model, “Ignore outliers in chart scaling” to remove outliers in the charts on the right of the user interface, “Tooltip sorting method” to allow users to select a method for sorting, “Smoothing” to allow users to select a smoothing level to smooth accuracy curves on the right of the user interface, “Horizontal Axis” to allow users to select a type (e.g., running steps, relative, and wall) of the horizontal of the accuracy curves, and “Runs” to write a regex to filter runs.

FIG. 18 depicts an example user interface according to example embodiments of the present disclosure. As shown in FIG. 18, “GRAPHS” option is selected. A graph on the right of the user interface shows an example structure of the training. The structure shows how the joint training of the PoD model and trainer can be performed. The structure shows a dataflow from the bottom to the top and shows each function that can be used to jointly train the PoD model and the trainer. Several tools are listed on the left of the user interface. Users can select the tools to process the graph on the right of the user interface. For example, input can be traced by activating “Trace input.”

Referring again to FIG. 2, the application data database 126 can store model metadata. The cloud storage database 124 can store machine-learned models (including both third party models and first party models) and training data. The training data can be uploaded by developers and can include validation data. Alternatively or additionally, the training data can be derived from large, public training datasets.

As illustrated, the console interface can communicate/interact with the model manager 120, machine learning manager 122, cloud storage database 124, and application data database 126 via one or more platform APIs. Example APIs are provided in the attached appendices. These APIs are provided as examples only. Different APIs can be used in addition or alternatively to the example APIs.

Appendix A provides example custom model APIs. Appendix A is incorporated into and forms a part of this specification.

Appendix B provides example vision model APIs. Appendix B is incorporated into and forms a part of this specification.

Appendix C provides example vision model APIs. Appendix C is incorporated into and forms a part of this specification.

Referring now to FIG. 3, FIG. 3 depicts a functional diagram of example console interface modes/states according to example embodiments of the present disclosure. As illustrated, in one workflow, a developer can progress through various console interfaces which respectively enable the developer to upload a model, check for compatibility, deploy the model, and then monitor performance of the model. In another workflow, the console can provide interfaces that respectively upload training data (e.g., to cloud storage buckets), optionally augment the training data, train and/or compress the model, and then deploy the model and monitor performance.

In some implementations, the console can provide a number of tools or user interfaces that assist the developer in generating the correct machine-learned model. As one example, the console can provide a set of use cases for developers to choose from, which will determine the target model architecture. In another example, the console can enable the developer to select or explore accuracy vs model size trade-off requirements.

FIG. 4 depicts a workflow diagram of an example computing system according to example embodiments of the present disclosure. More particularly, in some implementations, since model compression and/or conversion are long running tasks, they are not handled within the frontend server directly. In such cases, dedicated backend jobs are used to do the processing. FIG. 4 shows one example arrangement of such a system that includes a job scheduler with database queue to handle the job scheduling between the frontend and the backend.

In the backend job, the developer-provided model may need to be run. As a result, the process that runs the service can be sandboxed to provide privacy and security. For example, a cloud machine learning engine can be used.

In some implementations, at a high level, the platform can treat both model compression and conversion as a job. Thus, in some implementations, when a developer wants a model to be compressed or converted, the platform frontend server can create a job and insert it to database queue. The scheduler can handle the actual job scheduling, while the platform frontend server will keep on polling the status of the job, and report it back to the developer when it enters terminal state. The developer can also initiate the query to check the status of their jobs.

FIG. 5 depicts a workflow diagram of an example computing system according to example embodiments of the present disclosure. In particular, FIG. 5 depicts an example of a basic device-side flow. In particular, the application development platform and machine intelligence SDK allow developers to use custom models on the device. The API allows the application to perform inference using a custom model that's already on the device, where the developer either manually downloads the model file from somewhere or packages it within the application itself.

The platform also provides a model file hosting solution that is tightly integrated with the client-side SDK, which will provide the following features: A user interface part of platform console where the developer can manage their models; Model versioning, allowing the developer to specify active (or production) model and/or easily perform rollbacks; Automatically determining uploaded model compatibility with different machine learning library versions and only serving compatible models to compatible devices; and/or First class A/B testing support, allowing the developer to run experiments on different versions of their model.

Example Model Generation and Deployment Workflows

FIG. 6 depicts a flow chart diagram of an example process for generating and deploying machine-learned models according to example embodiments of the present disclosure while FIG. 7 depicts a workflow diagram of an example implementation the example process for generating and deploying machine-learned models according to example embodiments of the present disclosure.

In particular, aspects of the present disclosure are directed to an on-device machine intelligence SDK that forms a part of a cross-platform third party mobile machine learning platform that operates via APIs. For mobile developers building on-device machine learning features, training a model for mobile applications is still a big pain point for most developers. Furthermore, for a lot of mobile use cases the training workflows are pretty similar. Thus, the present disclosure provides tools to facilitate the whole model training workflow on the cloud.

Step 1: Model selection and design: For the majority of the use cases (e.g., mobile use cases), the training flow starts with a pre-trained model (e.g., Inception v3, MobileNets, etc.). The platform can provide access to a set of pre-trained models that cover some typical computer vision use cases and can guarantee to be converted to a mobile-optimized format. The set of selectable models can also cover other domains or custom models.

Step 2: Training data creation: The platform can assist developers to augment and manage their training data. Data augmentation can include adding more training samples (e.g., via an image search), leveraging crowd-sourcing platforms to provide labels, and introducing/or transformations of existing samples (e.g., add noises, rotations, perturbations, etc.). The platform can also provide data cleaning and visualization tools.

The platform provides a number of data format options, including, as examples: Raw data with labels and/or TF.example. The platform provides a number of model format options, including, as examples, SavedModel and/or Checkpoint.

Step 3: Model training: The training can include refining the pre-trained model (e.g., top layer only or more than top layer only). The training can also include fully automated training from scratch. Training can also optionally be done according to a joint training technique described herein.

Step 4: Model optimization for mobile: Since model size is critical for mobile applications, the platform can provide tools to automatically compress models with evaluation of performance and accuracy. Automatic model optimization can include re-training the model, where training data may be required.

Step 5: Model conversion for mobile: Once models are obtained that meet the required performance and accuracy, the platform can convert them to a mobile-optimized format ready for deployment. The conversion can include several steps (e.g., model freeze, TOCO conversion, etc.) with command line tools. These steps can be streamlined and information about errors can be provided via the platform console. In some implementations, the output models from the compression step can automatically be converted to the mobile format. Depending on the TOCO tool readiness, the models can be enforced to be in some standard architecture such as, for example, through POD compression (e.g., specified output model architecture).

Step 6: Model deployment and management: The application development platform can provide a targeting mechanism for developers to specify which models should be applied for which application versions, device types, and/or user segments. The platform can also provide a compatibility check to make sure models are compatible with the targeted machine learning library runtime. Lastly, the platform can host all the models for the developers and the applications can download/upgrade the models on the fly.

While the platform provides tools to help the complete training flow, the developers can also choose to leverage parts of the flow. For example, if the developers already have the model ready for deployment, they can upload their models and make use of step 6 only. If the developers already have a Tensorflow model for cloud inference, they can upload their Tensorflow models and make use of step 4 and/or 5 as well.

FIG. 8 depicts a swim lane diagram of an example process to upload machine-learned models for distribution according to example embodiments of the present disclosure. As illustrated, a user (developer) can (e.g., via their browser) initiate a model file upload. The platform backend API can create a new object with cloud storage and can return the cloud storage upload URL to the user. The user can upload the file to cloud storage and then inform the platform API when the upload has completed. The backend API can enqueuer a model compatibility check request.

A model compatibility service can dequeue the model compatibility check request and can get model information from the backend API. The API can return the cloud storage download URL. The model compatibility service can download the model file from cloud storage and can check compatibility and extract model metadata. The model compatibility service can update the model metadata with compatibility information.

Thus, in some implementations, model compatibility can be implemented as separate, asynchronous service. When model files are uploaded, a compatibility check request will be added to a database queue. The compatibility check service will then asynchronously perform the check. In some implementations, the model file may not be available for download until the compatibility check is complete.

FIG. 9 depicts a swim lane diagram of an example process to download machine-learned models according to example embodiments of the present disclosure. As illustrated, at an initial load, a machine intelligence SDK can request the model from the API. The API can look up the compatible version, authorize, and then get the download URL from cloud storage. The API can return the model information (e.g., download URL) to the machine intelligence SDK. The machine intelligence SDK can use the URL to download the model from cloud storage and can cache the downloaded model.

At a subsequent load, the SDK can get model information from the API. The API can return model information (including a download URL if appropriate). The SDK can download the new model, if necessary.

Example Machine Intelligence SDKs

FIGS. 10-14 depict example computing systems that include various different example implementations of the machine intelligence SDK. The machine intelligence SDK can be “fat,” “partially fat,” or “thin.”

The application development platform allows developers to either bundle the models together with the SDK or to dynamically download models to the SDK. In one example, the developers can upload their models on the platform console which will get synchronized to and cached on the device. Once on the device, the model is easily accessible to the on-device service via a simple API call.

Expanding on the SDK itself, the SDK may have “on-device backends” for some of these, i.e. calls to other modules (e.g., first party modules) or applications as part of its implementation (as shown in FIGS. 11-14). Alternatively, inclusion of all models and services within a single machine intelligence module as shown in FIG. 10 avoids duplicate machine learning library runtimes; optimizes the implementation, and maintains a single stack (e.g., C/C++ stack) for cross-platform usage.

In particular, FIG. 10 depicts a block diagram of an example computing system that includes a fat SDK according to example embodiments of the present disclosure. In particular, in the fat SDK, all of the machine intelligence models and services (e.g., vision, speech, text, custom, etc.) are unified into one SDK. More specifically, all of the models and a machine learning library/runtime (e.g., TFLite) can be contained within a single machine intelligence module as shown in FIG. 10.

Generally, a “fat” SDK means that all dependencies are pulled into one fat binary and it is statically linked to the application. Typically, the fat SDK does not update any part dynamically via updates. The fat SDK can interact with first party modules or applications however. A fat SDK avoids any machine learning library compatibility issues.

A “fat updateable” SDK is similar to a fat SDK (e.g., one fat binary statically linked to the application) except that aspects of the SDK can be dynamically updated without the full application update. In some implementations, whenever there is a newer version of first party models available on device, they will be dynamically loaded and run in the application's process. This enables quick updating of the machine learning runtime and the models but also introduces the possibility of machine learning library compatibility issues.

A “thin” SDK means that the SDK contains only client libraries and depends on the models being run inside first party support modules or applications. These can optionally still be run within the application's process. The benefit of thin SDKs is that the application package is smaller in size and implementation of the modules can be shared by multiple applications.

As an example, FIG. 11 depicts a block diagram of an example computing system that includes a thin SDK according to example embodiments of the present disclosure. As illustrated in FIG. 11, the machine intelligence module may call into other first party modules where applicable to share costs amongst clients. For some of those parts of the SDK, the client library can be in the SDK while the implementation is in a first party module or application.

Thus, various possible arrangements can also enable model management, including decisions regarding bundling in versus dynamic downloads. In particular, in some instances, the models (plus any databases needed for inference) may be quite large (˜MB) so the developer can be enabled to decide whether to go for the simplicity of bundling the models, or dynamically download those. For third party models, the developer can select the appropriate choice.

For first party models, the models could be all bundled within the SDK or dynamically downloaded, which may be controlled by the first party. Bundling the models within the SDK provides the following benefits: models available from the application install time; no need to wait for the downloading to happen; less network and power usage; and higher stability, less chance of a compatibility breakage from dynamically downloaded models.

In some implementations, large first party models can be shared amongst two or more applications. The sharing of the models amongst applications can, in one example, be achieved as follows: Make the models part of a first party module (i.e., have a separate updateable module and let it handle models/downloads. The first party module is not part of the ‘fat’ or ‘fat updateable’ SDK, but rather is in the ‘thin’ part of the SDK (i.e., the SDK pulls in only the client library of the module). The first party module can be exposed to the other parts of the SDK via a first party API.

In some implementations, there may be a separate machine learning library runtime for first party models that updates with the first party models and is not used for developer-owned models. This may assist in reducing compatibility issues.

Sharing the models amongst applications provides storage benefits/savings. That is, without sharing, redundant versions of the models will be a large hit on the storage (and application package size if bundled or power/data if they are downloaded) of the device.

In some implementations, the application development platform can distribute SDKs via static frameworks. A static framework can be a single statically-linked library coupled with headers (to be used in both Objective C and Swift) and some extra metadata (e.g., a module map). It is also possible to distribute SDKs as dynamically-loaded libraries.

In some implementations, distribution can occur via CocoaPods, where a CocoaPod is a json file specifying how to fetch the framework. The pod specification can point to a downloadable binary blob or, alternatively, the source code, for example, hosted externally.

A CocoaPod may contain one or more frameworks, although it is typical to only package one framework in a pod. The platform can automate most of the building, testing and deployment pipeline.

In some implementations, if there is already a module that exists in the SDK (e.g., mobile vision), it is easy to form a new SDK which pulls that dependency in as-is (e.g., as opposed to doing more tighter integration).

In some implementations, references can just be made to the symbols of the other library and it can be ensured that the user of the library gets both. With CocoaPods, it is easy to achieve. Some examples may use several dependencies such as Protobuf. The platform's build infrastructure can have provisions to ensure that the dependencies don't get statically linked at build time, preventing duplicate symbol breakages.

FIG. 12 depicts a block diagram of an example computing system that includes mobile vision models as part of an updatable first party support application according to example embodiments of the present disclosure. In particular, FIG. 12 depicts an architecture where only mobile vision models are provided via APIs to a first party support application while third party models are included in the machine intelligence SDK.

Thus, FIG. 12 shows an example that is part “fat” and part “updateable” SDK, where the custom models and a TFLite runtime are in the fat part and the mobile vision module (along with its tfmini runtime) is in the updateable part.

One example reason for having the mobile vision module as thin updateable (as opposed to fat updateable) is to share the storage space and downloading data of all models amongst all apps that use the SDK. The custom third party models can be updated through the platform console and cloud storage. The platform can provide compatibility tests that can be run from the platform console to help alleviate potential compatibility issues.

As for bundling the models: for mobile vision APIs, the models can be downloaded due to their size. For some third party custom models, developers can make a choice of bundling in the models or later updating the models via dynamic downloading.

FIG. 13 depicts a block diagram of an example computing system that includes mobile vision, text, and speech models as part of an updatable first party support application according to example embodiments of the present disclosure. That is, relative to FIG. 12, in FIG. 13 more base APIs (e.g., text, speech) are included in the support application, possibly each having their own module structure therein. Redundant common runtimes can optionally be removed.

FIG. 14 depicts a block diagram of an example computing system that includes an updatable first party support application that further performs both runtime and training according to example embodiments of the present disclosure. That is, all first party models and modules in the support application use the same runtime in the first party support application, thereby removing redundant runtimes, logging, and downloading of libraries.

The first party support application can also perform training. In other implementations, training can be part of a fat updateable SDK (as opposed to a thin updateable and shared amongst all apps) to provide privacy benefits for application-specific data storage.

The technology discussed herein makes reference to servers, databases, software applications, and other computer-based systems, as well as actions taken and information sent to and from such systems. The inherent flexibility of computer-based systems allows for a great variety of possible configurations, combinations, and divisions of tasks and functionality between and among components. For instance, processes discussed herein can be implemented using a single device or component or multiple devices or components working in combination. Databases and applications can be implemented on a single system or distributed across multiple systems. Distributed components can operate sequentially or in parallel.

The example SDK and application arrangements illustrated in FIGS. 10-14 are provided as examples only. Many different variations and combinations of these example arrangements can be made according to aspects of the present disclosure.

While the present subject matter has been described in detail with respect to various specific example embodiments thereof, each example is provided by way of explanation, not limitation of the disclosure. Those skilled in the art, upon attaining an understanding of the foregoing, can readily produce alterations to, variations of, and equivalents to such embodiments. Accordingly, the subject disclosure does not preclude inclusion of such modifications, variations and/or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art. For instance, features illustrated or described as part of one embodiment can be used with another embodiment to yield a still further embodiment. Thus, it is intended that the present disclosure cover such alterations, variations, and equivalents.

APPENDIX A Android r Here is an example of using the custom model API in Android: // Registers a model source to be downloaded from cloud. FirebaseModelManager.getInstance( ).register( new FirebaseCloudModelSource.Builder(MODEL_NAME) .setInitialDownloadConditions( new FirebaseModelDownloadConditions.Builder( ).build( )) .setUpdatesDownloadConditions( new FirebaseModelDownloadConditions.Builder( ) .setRequiresWifi(True) .setRequiresCharging(True) .build( )) .build( )); ) // Registers a model source to be downloaded from cloud. FirebaseModelManager.getInstance( ).regtster( new FirebaseLocalModelSource.Builder(LOCAL_MODEL_NAME) .setLocalFilePath(ABSOLUTE_PATH_TO_MODEL_ON_DEVICE) .build( )); ) // configures the model files to be used. Model sources with higher priority are // used if it is available. FirebaseModelOptions options = new FirebaseModelOptions.Builder( ) .setLocalModel(LOCAL_MODEL_NAME) .setCloudModel(MODEL_NAME) .build( ); // gets an instance of the model interpreter. FirebaseModelInterpreter firebaseInterpreter = FirebaseModelInterpreter.getInstance(options); // sets output formats. FirebaseModelInputOutputOptions inputOutputOptions = new FirebaseModelInputOutputOptions.Builder( ) .setInputFormat(0, FirebaseModelDataType.FLOAT, {1, 224, 224, 3}) .setOutputFormat(0, FirebaseModelDataType.FLOAT, {1, 1000}) .build( ); // configures inputs. FirebaseModelInputs inputs = new FirebaseModelInputs.Builder( ).add(bytebuffer).build( ); // runs model inference. Task<FirebaseModelOutputs> result = firebaseInterpreter.run(inputs, inputOutputOptions); .addOnSuccessListener( this, /** Activity */ new OnSuccessListener( ) { @Override void onSuccess(firebaseModelOutputs result) { // reads output. float[ ][ ] output = result.getResult( ).<float[ ][ ]>getOutput(0); } }) .addOnFailureListener( this, /** Activity */ new OnFailureListener( ) { @Override void onFailure(Throwable t) { ... } }); iOS

Swift: // Width, height and color channels used for the image in the tflite model. static let imgWidth: CGFloat = 224 static let imgHeight: CGFloat = 224 static let imgChannels = 3 // batch size x imgWidth x imgHeight x imgChannels static let inDims: [NSNumber] = [1, 224, 224, 3] // batch_size x labels count static let outDims: [NSNumber] = [1, 1001] static let tfModel: String = “mobilenet_v1_1.0_224” static let tfExt: String = “tflite” /// Detects objects on the specified image. /// - Parameter image: The image file name. func detectObjects(image: UIImage?) { guard let mPath = Bundle.main.path(forResource: tfModel, ofType; tfExt) else {  fatalError(“Couldn't find model file.”) } // Creates a local model source. let localSource = LocalModelSource(“LocalModel”, mPath) let modelManager = ModelManager.modelManager( ) modelManager.register(localsource) let mlOptions = ModelOptions( ) mlOptions.localModelName = “LocalModel” let ioType: ModelElementType = .uInt8 let ioOptions = ModelInputOutputOptions( ) let interpreter = ModelInterpreter(options: mlOptions) do {  try ioOptions.setInputFormat(index: 0, type: ioType, dimensions: inDims)  try ioOptions.setOutputFormat(index: 0, type: ioType, dimensions: outDims) } catch let error as NSError {  fatalError(“Interpreter creation error: \(error)”) } // Add the specified image to the input do {  // Create custom model inputs with pixel data from the image.  let input = ModelInputs( )  // Get pixel data from the image.  let cImageData = image?.pixelData( )  try input.addInput(cImageData as Any) } catch let error as NSError {  fatalError(“Interpreter add input error: \(error)”) } // Running the interpreter for the model with the passed input interpreter.run(inputs: input, options:ioOptions, completion: { (outputs : [ModelOutputs]?, error: Error?) in  if error != nil { // Get the output for the first batch. let output0: NSArray = try outputs.output(index: 0) // A result is an array of probabilities for labels. let result = (output0 as! NSArray) as Array // TODO: Build the coolest feature using the returned ‘result’.  } else { fatalError(“Face detection error”);  } }) } Objective-C: // Creates a cloud model source. FIRModelDownloadConditions *initialConditions = [[FIRModelDownloadConditions alloc] initWithChargingRequired:NO wifiRequired:NO idleRequired:NO]; FIRModelDownloadConditions *updateConditions = [[FIRModelDownloadConditions alloc] initWithChargingRequired:YES wifiRequired:YES idleRequired:YES]; FIRCloudModelSource *cloudSource = [[FIRCloudModelSource alloc] initWithModelName:@“CloudModel” enableModelUpdates:YES  initialConditions:initialConditions updateConditions:updateConditions]; FIRModelManager *modelManager = [FIRModelManager modelManager]; [modelManager registerCloudModelSource:cloudSource]; // Creates a fallback local model source. FIRLocalModelSource *localSource = [[FIRLocalModelSource alloc] initWithModelName:@“LocalModel”  path:@“/path/to/local/model.tflite”]; [modelManager registerLocalModelSource:localSource]; // Creates a custom model interpreter. FIRModelOptions *options = [[FIRModelOptions alloc] initWithCloudModelName:@“CloudModel” LocalModelName:@“LocalModel”]; FIRModelInterpreter interpreter = [FIRModelInterpreter modelInterpreterWithOptions:options]; NSError *error = nil; // Configures the input and output options. FIRModelInputOutputOptions *ioOptions = [[FIRModelInputOutputOptions alloc] init]; NSArray<NSNumber *> *inputDims = [NSArray arrayWithObjects: [NSNumber numberWithUnsignedInteger:1], [NSNumber numberWithUnsignedInteger:224], [NSNumber numberWithUnsignedInteger:224], [NSNumber numberWithUnsignedInteger:3], nil]; [ioOptions setInputFormatForIndex:0 type:FIRModelElementTypeFloat32 dimensions:inputDims  error:&error]; // Check and handle any error. NSArray<NSNumber *> *outputDims = [NSArray arrayWithObjects: [NSNumber numberWithUnsignedInteger:1], [NSNumber numberWithUnsignedInteger:1001], nil]; [ioOptions setOutputFormatForIndex:0  type:FIRModelElementTypeFloat32  dimensions:outputDims error:&error]; // Check and handle any error. // Creates the input data. FIRModelInputs *inputs = [[FIRModelInputs alloc] init]; [inputs addinput:inputData error:&error]; // Check and handle any error. // Defines the completion callback handler. FIRModelInterpreterRunCallback completion = {circumflex over ( )}(( FIRModelOutputs * _Nullable outputs, NSError * _Nullable error) {  if (error != nil) { // Handle the error. NSLog(@“Error in running model: %@”, error.localizedDescription);  } else { id output = [outputs outputAtIndex:0]; // Build the coolest feature using the output.  } }); // Runs the custom model with the input data, [interpreter runWithInputs:inputs options:ioOptions completion:completion];

Change Details

com.google.firebase.ml.custom class FirebaseModelManager A central manager of cloud model sources. static FirebaseModelManager getInstance( ); Create an instance of custom model cloud model manager for a default FirebaseApp, static FirebaseModelManager getInstance( Same as above with a given FirebaseApp. @NonNull FirebaseApp app); void register( Register a new cloud model source. Throw @NonNull FirebaseCloudModelSource an exception to register twice under the cloudModelSource) same name. void register( Register a new local model source. Throw @NonNull FirebaseLocalModelSource an exception to register twice under the localModelSource) same name. com.google.firebase.ml.custom class FirebaseLocalModelSource.Builder Represent the firebase cloud model source. Builder(@NonNull String modelName) Sets model name for model registration, REQUIRED. This name should be unique among all local model names. Builder setLocalFilePath(@NonNull String Sets absolute file path of a local file, localFilePath) either the local file or the asset file should be filled. Builder setAssetFileSubPath( Sets the file subpath under asset @NonNull String assetFileSubPath) folder. Either the local file or the asset file should be filled. FirebaseLocalModelSource build( ); Create a cloud model source com.google.firebase.ml.custom class FirebaseCloudModelSource.Builder Represent the firebase cloud model source. Builder(@NonNull String modelName) Sets model name for model registration, REQUIRED. This name should be unique among all cloud names, and should be the same model name in firebase console. Builder setFilePath( Sets initial download conditions for @NonNull FirebaseModelDownloadConditions conditions) model registration Builder setUpdateDownloadConditions( Sets updates download conditions @NonNull FirebaseModelDownloadConditions conditions) for model registration Builder enableModelUpdates(boolean enable) Sets model updates enable or not. FirebaseCloudModelSource build( ); Create a cloud model source com.google.firebase.ml.custom class FirebaseModelInterpreter Represent the firebase machine learning service. static FirebaseModelInterpreter getInstance( Create an instance of custom model @NonNull FirebaseModelOptions options); interpreter with a given option. Note: it always returns a new interpreter instance. However, if two interpreters are created with the same options, they share the same model instance and use reference count to manage the mode lifecycle. static FirebaseModelInterpreter getInstance( Same as above with a given @NonNull FirebaseApp app, FirebaseApp. @NonNull FirebaseModelOptions options); com.google.firebase.ml.custom public class FirebaseModelOptions.Builder Builder to build FirsbaseModelOptions which specifying a model Builder setLocalModelSource( Sets a local model name, which should @NonNull String localModelName)); be registered model name. Builder setCloudModelSource( Sets a cloud model source, which @NonNull String cloudModelName); should be registered model name. The model will be downloaded from cloud under the hood. FirebaseModelOptions build( ); Builds the options. com.google.firebase.ml.custom public class FirebaseModelDownloadConditions.Builder Interface to build download conditions. Builder requireWifi( ); If true, only download the model when wifi is on. Builder requireCharging( ); If true, only download the model when it is charging. Builder requireIdle( ); If true, only download the model when it is idle. FirebaseModelDownloadConditions build( ); Builds a FirebaseModelDownloadConditions com.google.firebase.ml.custom public class FirebaseModelInterpreter Represents the firebase interpreter for custom models. Task<FirebaseModelOutputs> run( Runs model inference with inputs @NonNull FirebaseModelInputs inputs, and data configurations. @NonNull FirebaseModelInputOutputOptions outputoptions); int getInputIndex( Get index of an input with the @NonNull String opName); given name; int getOutputIndex( Get index of an output with the @NonNull String opName); given name. com.google.firebase.ml.custom public class FirebaseModelDataType Represents the supported data types in Firebase custom model @IntDef({ FLOAT32, INT32, BYTE, LONG, }) public @interface Datatype { } com.google.firebase.ml.custom public class FirebaseModelInputOutputOptions.Builder Builder class to specify input and output data types and dimensions. Builder( ); Creates a builder to build the class. Builder( Creates a builder with an existing @NonNull FirebaseModelInputOutputOptions options); FirebaseModelOutputFormats. Builder setInputFormat(int index, @DataType int Sets data type and dimensions for type, @NonNull int[ ] dims); index-th input. Builder setOutputFormat(int index, @DataType int Sets data type and dimensions for type, @NonNull int[ ] dims); index-th output. FirebaseModelInputOutputOptions build( ); Builds a FirebaseModelInputOutputOptions. com.google.firebase.ml.custom public class FirebaseModelInputs.Builder Builder to build a class to hold input data. Builder add(@NonNull ByteBuffer input); Each input is a direct ByteBuffer. The TFLite model may have multiple input ByteBuffer. The Bytebuffer content should have the same byte size with the input options. FirebaseModelInputs build( ); com.google.firebase.ml.custom public class FirebaseModelOutputs Stores inference results. <T> T getOutput(int index); Gets index-th output as type T. T could be an array or multidimensional array of float, int, byte, or long. If the index does not exist, an IllegalArgumentException will be thrown. Example: To get 0-th output as a 2-dimensional byte array: byte[ ][ ] probs = FirebaseModelOutputs.<byte[ ][ ]>getOutput(0); If the output index does not exist, an IllegalArgumentException will be thrown. If type argument ‘T’ does not match the corresponding data type and dimension specified in the model file, ClassCastException will be thrown. iOS³

NS_SWIFT_NAME(FirebaseModelManager) @interface FIRModelManager: NSObject A manager of model sources. + (instancetype)modelManager Gets the custom model manager for the NS_SWIFT_NAME(modelManager( )) default Firebase app. The returned model manager is thread safe. Custom models hosted in non-default Firebase apps are currently not supported. − (BOOL) registerCloudModelSource: Registers a cloud model to be used by the (FIRCloudModelSource *)cloudModelSource custom model interpreter. The model name is unique to each custom cloud model and can only be registered once with a given instance of the ‘ModelManager’. The model name should be the same name used when uploading the custom model to the Firebase Console. It's OK to separately register a cloud model and a local model with the same name for a given instance of the ‘ModelManager’. − (BOOL)registerLocalModelSource: Registers a local model to be used by the (FIRLocalModelSource *)localModelSource custom model interpreter. The model name is unique to each custom local model and can only be registered once with a given instance of the ‘ModelManager’. It's OK to separately register a cloud model and a local model with the same name for a given instance of the ‘ModelManager’. − (nullable FIRCloudModelSource *) Gets the registered cloud model source with cloudModelSourceForModelName: the given model name. Returns nil if the (NSString *)modelName model name was never registered with this NS_SWIFT_NAME(cloudModelSource(modelName:)) model manager. − (nullable FIRLocalModelSource *) Gets the registered local model source with the localModelSourceForModelName: given model name. Returns nil if the model (NSString *)modelName name was never registered with this model NS_SWIFT_NAME(localModelSource(modelName:)) manager. NS_SWIFT_NAME(ModelOptions) @interface FIRModelOptions: NSObject Options for specifying a model. Either localModelName or cloudModelName must be specified. When both are provided, cloud model has higher priority after it is downloaded; local model will be used before cloud model is downloaded. @property(nonatomic, nullable) NSString Name of a model stored in a file on *localModelName the device. @property(nonatomic, nullable) NSString Name of a model to be downloaded *cloudModelName from the cloud. − (instancetype)initWithCloudModelName: Creates a new instance with the given (nullable NSString *)cloudModelName local and/or cloud model name. At localModelName: least one model name must be (nullable NSString *)localModelName provided. If both cloud and local NS_DESIGNATED_INITIALIZER model names are provided, then the cloud model takes priority. − (instancetype)init NS_UNAVAILABLE NS_SWIFT_NAME(LocalModelSource) @interface FIRLocalModelSource: NSObject Source of a custom model stored locally on the device. @property(nonatomic, copy, readonly) A unique name of the local model. NSString *modelName @property(nonatomic, copy, readonly) The absolute file path of the local model source. NSString *path − (instancetype)initWithModelName: Creates an instance of LocalModelSource with (NSString *)modelName path:(NSString the given path. *)path; NS_SWIFT_NAME(CloudModelSource) @interface FIRCloudModelSource: NSObject Source of a custom model to be downloaded from the cloud. @property(nonatomic, copy, readonly) A unique name of the custom model. NSString *modelName @property(nonatomic, readonly) Whether model updates should be enabled. BOOL enableModelUpdates If disabled, the model is downloaded only once. Otherwise, model updates will be checked periodically after the model interpreter is initialized. @property(nonatomic, readonly, nullable) Download conditions for the initial model FIRModelDownloadConditions from the cloud. *initialConditions @property(nonatomic, readonly, nullable) Subsequent update conditions for the model. FIRModelDownloadConditions If ‘nil’ is passed to the initializer, the default *updateConditions update conditions are set, but are only used if ‘enableModelUpdates’ is ‘YES’. − (instancetype)initWithModelName: Creates an instance of CloudModelSource (NSString *)modelName with the given name and download enableModelUpdates: conditions (BOOL)enableModelUpdates initialconditions: (FIRModelDownloadConditions *) initialconditions updateConditions: (nullable FIRModelDownloadConditions *) updateConditions NS_DESIGNATED_INITIALIZER − (instancetype)init NS_UNAVAILABLE NS_SWIFT_NAME(ModelDownloadConditions) @interface FIRModelDownloadConditions: NSObject Source of a custom model to be downloaded from the cloud. @property(nonatomic, readonly) BOOL Whether to download the model only when Wifi isWifiRequired is connected. Defaults to NO. @property(nonatomic, readonly) BOOL Indicates whether the device should be in an isIdleRequired idle state for downloading. Default to NO’. NS_SWIFT_NAME(ModelInterpreter) @interface FIRModelInterpreter: NSObject A Firebase interpreter for a custom model. + (nullable instancetype) Gets the custom model manager  modelInterpreterWithOptions:(FIRModelOptions *)options for the default Firebase app. The returned model manager is thread safe. Custom models hosted in non-default Firebase apps are currently not supported. typedef void ({circumflex over ( )}FIRModelInterpreterRunCallback)( The callback to invoke when the FIRModelOutputs * _Nullable outputs, an interpreter completes a single NSError * _Nullable error) run of the model. NS_SWIFT_NAME(ModelInterpreterRunCallback) − (void)runWithInputs:(FIRModelInputs *)inputs Runs model inference with the options:(FIRModelInputOutputOptions *)options given inputs and data options. completion: (FIRModelInterpreterRunCallback)completion NS_SWIFT_NAME(run(inputs:options:)) typedef void A block containing the index for an ({circumflex over ( )}FIRModelInterpreterInputOutputOpIndexCallback)( input or output op. NSNumber *_Nullable index, NSError *_Nullable error) NS_SWIFT_NAME(  ModelInterpreterInputOutputOpIndexCallback) − (void)inputIndexForOp:(NSString *)opName Gets the index of an input with the  Completion: given name. (FIRModelInterpreterInputOutputOpIndexCallback)comple tion NS_SWIFT_NAME(inputIndex(opName:completion:)) − (void)outputIndexForOp:(NSString *)opName Gets the index of an output with Completion: the given name. (FIRModelInterpreterInputOutputOpIndexCallback)comple tion NS_SWIFT_NAME(outputIndex(opName:completion:)) NS_SWIFT_NAME(ModelInputOutputOptions) @interface FIRModelInputOutputOptions: NSObject Options of a custom model specifying input and output data types and dimensions. typedef NS_ENUM(NSUInteger, FIRModelElementType) { This enum specifies the /** Element type unknown/undefined. */ type of elements in the FIRModelElementTypeUnknown = 0, custom model's input or /** 32-bit single precision floating point. */ output. FIRModelElementTypeFloat32 = 1, /** 32-bit signed integer. */ FIRModelElementTypeInt32, /** 8-bit unsigned integer. */ FIRModelElementTypeUInt8, /** 64-bit signed integer. */ FIRModelElementTypeInt64, } NS_SWIFT_NAME(ModelDataType) − (BOOL)setInputFormatForIndex:(NSUInteger)index Sets the type and  type:(FIRModelDataType)type dimensions of the index-th dimensions:(NSArray<NSNumber *> *)dimensions input. error:(NSError **)error NS_SWIFT_NAME(setInputFormat(index:type:dimensions:)) − (BOOL)setOutputFormatForIndex:(NSUInteger)index Sets the type and  type:(FIRModelDataType)type dimensions of the index-th dimensions:(NSArray<NSNumber *> *)dimensions output. error:(NSError **)error NS_SWIFT_NAME(setOutputFormat(index:type:dimensions:)) NS_SWIFT_NAME(ModelInputs) @interface FIRModelInputs: NSObject Input data for a Firebase custom model. − (BOOL)addInput:(id)input Adds an input at the next index (starting from 0). Input error:(NSError **)error can be NSData, or a one-dimensional or multi-dimensional array of NSNumbers (float, int, char, long). NS_SWIFT_NAME(ModelOutputs) @interface FIRModelOutputs: NSObject Inference results of a Firebase custom model. − (nullable id)outputAtIndex:(NSUInteger)index Gets index-th output, which could be error:(NSError **)error NSData, or an array or multidimensional NS_SWIFT_NAME(output(index:)) array of NSNumbers (float, int, long) or NSData. ³ Unless explicitly indicated otherwise, all iOS APIs assume nonnull wherever applicable.

APPENDIX B Android - Cloud Face Detector // Define the options for cloud detector. FirebaseVision 

 DetectorOptions options = new FirebaseVisionCloudDetectorOptions.Builder( ) .setMaxResults(10) .setModelType(FirebaseVisionCloudDetectorOptions.STABLE_MODEL) .build( ); // Get an instance of FirebaseVisionCloudFaceDetector. FirebaseVision 

 Detector detector = FirebaseVision.getInstance( ) .get 

 Detector (options...); // Specify the metadata for the input image. FirebaseVisionImageMetadata metadata = FirebaseVisionImageMetadata.newBuilder( ) .setWidth(640).setHeight(480).setRotation(Rotation.Rotation_0) .setFormat(ImageFormat.IMAGE_FORMAT_NV21).build( ); // Detect face in the image with listeners. Task<List<FirebaseVision 

 Face>> result = detector.detect(FirebaseVisionImage.fromByteBuffer(bytebuffer, metadata)) .addOnSuccessListener( this, /** Activity */ new OnSuccessListener( ) { @Override void onSuccess(List<FirebaseVision 

 Face> faces) { for (FirebaseVision 

 Face face : faces) { Log.i(TAG, “face center position X: ” + face.getBoundingBox( ).centerX( )); Log.i(TAG, “face center position Y: ” + face.getBoundingBox( ).centerY( )); if (face instanceof FirebaseVisionCloudFace) { // Use a Cloud specific feature after cast. } } }}) .addOnFailureListener( this, /** Activity */ new OnFailureListener( ) { @Override void onFailure(Throwable t) { ... } }); Landmark detector // Get an instance of FirebaseVisionCloudFaceDetector with default option. FirebaseVisionCloudLandmarkDetector detector = FirebaseVision.getInstance( ) .getVisionCloudLandmarkDetector( ); // Specify the metadata for the input image. FirebaseVisionImageMetadata metadata = FirebaseVisionImageMetadata.newBuilder( ) .setWidth(640).setHeight(480).setRotation(Rotation.Rotation_0) .setFormat(ImageFormat.IMAGE_FORMAT_NV21).build( ); // Detect face in the image with listeners. Task<List<FirebaseVisionCloudLandmark>> result = detector.detect(FirebaseVisionImage.fromByteBuffer(bytebuffer, metadata)) .addOnSuccessListener ( this, /** Activity */ new OnSuccessListener( ) { @Override void onSuccess(List<FirebaseVisionCloudLandmark> landmarks) { for (FirebaseVisionCloudLandmark landmark : landmarks) { Log.i(TAG, “Detected Landmark: ” + landmark,getLandmark( )); } }}) .addOnFailureListener( this, /** Activity */ new OnFailureListener( ) { @Override void onFailure(Throwable t) { ... } });

iOS (Objective C)

We will show the sample code of label detection using Firebase ML Cloud ML Vision label detection API. Other Cloud ML Vision APIs are similar.

// Get the instance of the ‘FIRVision’ for the default ‘FIRApp’. FIRVision *vision = [FIRVision vision]; // Define the options for a label detector. FIRVisionCloudDetectorOptions *options = [[FIRVisionCloudDetectorOptions alloc] init]; options.modelType = FIRVisionCloudModelTypeLatest; options.maxResults = 20; // Get an instance of ‘FIRVisionCloudLabelDetector’. FIRVisionCloudLabelDetector *detector = [vision cloudLabelDetectorWithOptions:options]; // Define the metadata of the image for detection. FIRVisionImageMetadata *metadata = [[FIRVisionImageMetadata alloc] init]; metadata.orientation = FIRVisionDetectorImageOrientationTopRight; // Define the FIRVisionImage for detection. FIRVisionImage *image = [[FIRVisionImage alloc] initWithImage:uiImage metadata:imageMetadata]; // Invoke label detection in the image. [detector detectInImage:image completion:{circumflex over ( )}(NSArray<FIRVisionCloudLabelFeature *> *labels, NSError *error) {  if (error != nil) { // Handle the error. NSLog(@“Label detection error: %@”, error.localizedDescription); return;  } else if (labels != nil) { // TODO: Build the coolest feature using the returned label features in ‘labels’. } }];

iOS (Swift)

We will show the sample code of face detection using Firebase ML Cloud ML Vision label detection API. Other Cloud ML Vision APIs are similar.

// Define the options for a label detector. let options = VisionLabelDetectorOptions( ) options.modeType = .accurate options.landmarkType = .all options.classificationType = .all options.minFaceSize = CGFloat(0.2) options.isTrackingEnabled = true // Get an instance of ‘VisionCloudLabelDetector’. let labelDetector = Vision.vision( ).cloudFaceDetector(options:options) // Define the metadata of the image for detection. let metadata = VisionImageMetadata( ) metadata.orientation = VisionDetectorImageOrientation.topRight // Define the VisionImage for detection. let image = VisionImage(image:uiImage!, metadata:metadata) // Invoke label detection in the image. labelDetector.detect(in: image) { labels, error in if let error = error { // Handle the error. print(“Label detection error: \(error.localizedDescription)”) return } else if let labels = labels {  // TODO: Build the coolest feature using the returned face features in ‘labels’. } } Chang Details

com.google.firebase.ml.vision class FirebaseVision Represent the firebase cloud vision. (cloud detectors) FirebaseVisionCloudFaceDetector getVisionCloudFaceDetector( Gets a cloud face detector that @NonNull FirebaseVisionCloudDetectorOptions options) can detect faces in a supplied image. FirebaseVisionCloudFaceDetector getVisionCloudFaceDetector( ) Gets a cloud face detector with a default option. FirebaseVisionCloudLogoDetector getVisionCloudLogoDetector( Gets a cloud logo detector that @NonNull FirebaseVisionCloudDetectorOptions options){ can detect logos in a supplied image. FirebaseVisionCloudLogoDetector getVisionCloudLogoDetector( ) Gets a cloud logo detector with a default option. FirebaseVisionCloudLabelDetector getVisionCloudLabelDetector( Gets a cloud label detector that @NonNull FirebaseVisionCloudDetectorOptions options) can detect logos in a supplied image. FirebaseVisionCloudLabelDetector getVisionCloudLabelDetector( ) Gets a cloud label detector with a default option. FirebaseVisionCloudImagePropertiesDetector Gets an image properties getVisionCloudImagePropertiesDetector( detector that can detect logos in a @NonNull FirebaseVisionCloudDetectorOptions options) supplied image. FirebaseVisionCloudImagePropertiesDetector Gets an image properties getVisionCloudImagePropertiesDetector( ) detector with a default option. FirebaseVisionCloudTextDetector getVisionCloudTextDetector( Gets a cloud text detector that @NonNull FirebaseVisionCloudDetectorOptions options) can detect logos in a supplied image. FirebaseVisionCloudTextDetector getVisionCloudTextDetector( ) Gets a cloud text detector with a default option. FirebaseVisionCloudDocumentTextDetector Gets a cloud document text getVisionCloudDocumentTextDetector( detector that can detect logos in a  @NonNull FirebaseVisionCloudDetectorOptions options) supplied image. FirebaseVisionCloudDocumentTextDetector Gets a cloud document text getVisionCloudDocumentTextDetector( ) detector with a default option. FirebaseVisionCloudLandmarkDetector Gets a cloud landmark detector getVisionCloudLandmarkDetector( that can detect logos in a supplied @NonNull FirebaseVisionCloudDetectorOptions options) image. FirebaseVisionCloudLandmarkDetector Gets a cloud landmark detector getVisionCloudLandmarkDetector( ) with a default option. FirebaseVisionCloudWebSearcher getVisionCloudWebSearcher( Gets a cloud web searcher @NonNull FirebaseVisionCloudDetectorOptions options) detector that can detect logos in a supplied image. FirebaseVisionCloudWebSearcher getVisionCloudWebSearcher( ) Gets a cloud web searcher detector with a default option. FirebaseVisionCloudSafeSearchDetector Gets a cloud safe search getVisionCloudSafeSearchDetector( detector that can detect logos in a @NonNull FirebaseVisionCloudDetectorOptions options) supplied image. FirebaseVisionCloudSafeSearchDetector Gets a cloud safe search  getVisionCloudSafeSearchDetector( ) detector with a default option. FirebaseVisionCloudCropHintsDetector Gets a cloud crop hints detector getVisionCloudCropHintsDetector( that can detect logos in a supplied @NonNull FirebaseVisionCloudDetectorOptions options) image. FirebaseVisionCloudCropHintsDetector Gets a cloud crop hints detector getVisionCloudCropHintsDetector( ) with a default option. com.google.firebase.ml.vision.cloud interface FirebaseVisionCloudDetectorOptions Represents the vision request to cloud vision APIs. int getMaxResults( ) Gets maximum number of results to be detected. @IntDef({ Model types of cloud vision detector. STABLE_MODEL, LATEST_MODEL }) @interface ModelType { } int getModelType( ) Gets the detector model. com.google.firebase.ml.vision.cloud interface FirebaseVisionCloudDetectorOptions.Builder Represents the builder of a vision request to cloud vision APIs. Builder setMaxResults(int maxResults) Sets maximum number of results of this type. It would not take effects in TEXT_DETECTION and DOCUMENT_TEXT_DETECTION. Default is 10 Builder setModelType(@ModelType int Sets model for the detection model) Default is STABLE_MODEL FirebaseVisionCloudDetectorOptions build( ) com.google.firebase.ml.vision class FirebaseVisionLatLng Represents the builder of an image context. double getLatitude( ) Gets the latitude in degrees. It must be in the range [−90.0, +90.0]. double getLongitude( ) Gets the longitude in degrees. It must be in the range [−180.0, +180.0].

Detectors

Face Detector com.google.firebase.ml.vision.cloud.face class FirebaseVisionCloudFaceDetector Represents the cloud vision face detector Task<List<FirebaseVisionCloudFace>> detectInImage( Detects faces for supplied image. @NonNull FirebaseVisionImage image) Logo Detector com.google.firebase.ml.vision.cloud.logo class FirebaseVisionCloudLogoDetector Represents the cloud vision logo detector Task<List<FirebaseVisionCloudLogo>> detectInImage( Detects logos for supplied image. @NonNull FirebaseVisionImage image) Label Detector com.google.firebase.ml.vision.cloud.label class FirebaseVisionCloudLabelDetector Represents the cloud vision label detector Task<List<FirebaseVisionCloudLabel>> detectInImage( Detects labels for supplied image. @NonNull FirebaseVisionImage image) Image Properties Detector com.google.firebase.ml.vision.cloud.imageproperties class FirebaseVisionCloudImagePropertiesDetector Represents the cloud vision image properties detector Task<FirebaseVisionCloudImageProperties> detectInImage( Detects image properties for supplied @NonNull FirebaseVisionImage image) image. Text Detector Detects and extracts text via OCR within an image with support for a broad range of languages. It also features automatic language identification. com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudTextDetector Represents the cloud vision text detector Task<FirebaseVisionCloudText> detectInImage( Detects text for supplied image. @NonNull FirebaseVisionImage image) Supports broad range of langs, language id. Document Text Detector Detects dense document text in an image using OCR. com.google.firebase.ml.vision.cloud.document class FirebaseVisionCloudDocumentTextDetector Represents the cloud vision document text detector Task<FirebaseVisionCloudText> detectInImage( Detects dense document text for @NonNull FirebaseVisionImage image) supplied image. Landmark Detector com.google.firebase.ml.vision.cloud.landmark class FirebaseVisionCloudLandmarkDetector Represents the cloud vision landmark detector Task<List<FirebaseVisionCloudLandmark>> Detects landmarks for supplied detectInImage(@NonNull FirebaseVisionImage image) image. Web Searcher com.google.firebase.ml.vision.cloud.document class FirebaseVisionCloudWebSearcher Represents the cloud vision web searcher Task<FirebaseVisionCloudWebDetectionResult> Returns relevant web search results detectInImage(@NonNull FirebaseVisionImage image) for supplied image. Safe Search Detector com.google.firebase.ml.vision.cloud.safesearch class FirebaseVisionCloudSafeSearchDetector Represents the cloud vision document text detector Task<FirebaseVisionCloudSafeSearch> Returns safe search likelihood (for detectInImage(@NonNull FirebaseVisionImage image) example, adult, spoof, medical, violence) for supplied image. Crop Hints Detector com.google.firebase.ml.vision.cloud.crophints class FirebaseVisionCloudCropHintsDetector Represents the cloud vision corp hints detector Task<List<FirebaseVisionCloudCropHint>> Detects crop hints for supplied image. detectInImage(@NonNull FirebaseVisionImage image)

Response Classes

Face Response com.google.firebase.ml.vision.cloud.face class FirebaseVisionCloudFace Represents the cloud vision face FirebaseVisionCloudFaceLandmark Get cloud face landmark based on given landmark type. getLandmark( @CloudFaceLandmark int landmarkType) float getDetectionConfidence( ) Gets the detection confidence. Range [0, 1] float getLandmarkingConfidence( ) Gets the landmark confidence. Range [0, 1] float getSorrowProbability( ) Gets sorrow probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getAngerProbability( ) Gets anger probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely float getSurpriseProbability( ) Gets surprise probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely float getUnderExposedProbability( ) Gets under exposed probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getBlurredProbability( ) Gets blurred probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getHeadwearProbability( ) Gets head wear probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getSmilingProbability( ) Gets smiling probability. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getHeadEulerAngleX( ) Pitch angle, which indicates the upwards/downwards angle that the face is pointing relative to the image's horizontal plane. Range [−180, 180] float getHeadEulerAngleY( ) Yaw angle, which indicates the leftward/rightward angle that the face is pointing relative to the vertical plane perpendicular to the image. Range [−180, 180]. float getHeadEulerAngleZ( ) Roll angle, which indicates the amount of clockwise/anti-clockwise rotation of the face relative to the image vertical about the axis perpendicular to the face. Range [−180, 180]. @Nullable Bounding box Rect getBoundingBox( ) com.google.firebase.ml.vision.cloud.face class FirebaseVisionCloudFaceLandmark Represents the cloud vision face landmark @IntDef { List of cloud face landmarks ... (link) } @interface CloudFaceLandmark { } @CloudFaceLandmark Gets the CloudFaceLandmark type int getCloudFaceLandmarkType( ) FirebaseVisionPoint getPosition( ) Landmark positions may fall outside the bounds of the image if the face is near one or more edges of the image. Therefore it is NOT guaranteed that 0 <= x < width or 0 <= y < height. @return a 3D point for the landmark position. Logo Response com.google.firebase.ml.vision.cloud.logo class FirebaseVisionCloudLogo Represents the cloud vision logo @Nullable Gets opaque entity ID. Some IDs may be String getEntityId( ) available in [Google Knowledge Graph Search API](https://developers.google.com/knowledge-graph/) @Nullable Gets logo. String getLogo( ) @Nullable Gets image region of the detected logo. Rect getBoundingBox( ) float getConfidence( ) Gets overall confidence of the result. Range [0, 1]. Label Response com.google.firebase.ml.vision.cloud.label class FirebaseVisionCloudLabel Represents the label detected via cloud vision APIs @Nullable Gets opaque entity ID. Some IDs may be String getEntityId( ) available in [Google Knowledge Graph Search API](https://developers.google.com/knowledge-graph/). @Nullable Gets label. String getLabel( ) float getConfidence( ) Gets overall confidence of the result. Range [0, 1]· Image Properties Response com.google.firebase.ml.vision.cloud.imageproperties class FirebaseVisionCloudImageProperties Represents the cloud vision image properties @Nullable Returns the dominant colors info in List<ColorInfo> getDominantColorsAnnotation( ) the image. com.google.firebase.ml.vision.cloud.imageproperties class FirebaseVisionCloudImageProperties.ColorInfo Represents the cloud vision image properties color info ColorInfo class definition link Represents color information consisting of RGB channels, confidence, and the fraction of the image that the color occupies in the image. com.google.firebase.ml.vision.cloud.imageproperties class FirebaseVisionCloudImageProperties.Color Represents the cloud vision image properties color Color class definition link Represents RGBA components of color. Text and Full Document Text Response com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText Represents the cloud vision text List<Page> getPages( ) Gets text, pages String getText( ) Gets text com.google.firebase.ml.vision.cloud.text class FirebaseCloudVisionText.TextProperty Represents the cloud vision text List<DetectedLanguage> Gets a list of detected languages together with getDetectedLanguages( ) confidence @Nullable Gets detected start or end of a text segment. Detected Break getDetectedBreak( ) com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText.Page Represents the cloud vision text public List<Block> getBlocks( ) List of blocks in the page. @Nullable Gets additional information detected for the page. TextProperty getTextProperty( ) int getWidth( ) Gets the width of the page. int getHeight( ) Gets the height of the page. float getConfidence( ) Gets confidence of the OCR results for the page. Range [0, 1]. com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText.Block Represents the cloud vision text block Block methods link Similar to pages, contains paragraphs com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText.Paragraph Represents the cloud vision text paragraph Paragraph methods link Similar to block, contains words com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText.Word Represents the cloud vision text Word methods link Similar to paragraph, contains symbol com.google.firebase.ml.vision.cloud.text class FirebaseVisionCloudText.Symbol Represents the cloud vision text Symbol methods link Basic element Landmark Response com.google.firebase.ml.vision.cloud.landmark class FirebaseVisionCloudLandmark Represents the cloud vision landmark @Nullable Gets opaque entity ID. Some IDs may be available in String getEntityId( ) [Google Knowledge Graph Search API](https://developers.google.com/knowledge-graph/) @Nullable Gets landmark. String getLandmark( ) @Nullable Gets image region of the detected logo. Rect getBoundingBox( ) float getConfidence( ) Gets overall confidence of the result. Range [0, 1], List<FirebaseVisionLatLng> getLocations( ) Gets the location information for the detected entity. Multiple LocationInfo elements can be present because one location may indicate the location of the scene in the image, and another location may indicate the location of the place where the image was taken. Location information is usually present for landmarks. Web Searcher Response com.google.firebase.ml.vision.cloud.websearch class FirebaseVisionCloudWebDetectionResult Represents the cloud vision web search result List<WebEntity> getWebEntitvList( ) Returns deduced entities from similar images on the internet. List<WebImage> getFullMatchingImagesList( ) Returns fully matching images from the Internet, which can include resized copies of the query image. List<WebImage> getPartialMatchingImagesList( ) Returns partial matching images from the Internet List<WebPage> Returns web pages containing the matching getPagesWithMatchingImagesList( ) images from the Internet. List<WebImage> getVisuallySimilarImagesList( ) Returns visually similar image results. List<WebLabel> getBestGuessLabelsList( ) Returns best guess text labels for the request image. Safe Search Responce com.google.firebase.ml.vision.cloud.safesearch class FirebaseVisionCloudSafeSearch Represents the cloud vision document text detector float getAdultLikelihood( ) Represents the adult content likelihood for the image. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getSpoofLikelihood( ) Spoof likelihood. The likelihood that an modification was made to the image's canonical version to make it appear funny or offensive. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getMedicalLikelihood( ) Likelihood that this is a medical image. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getViolenceLikelihood( ) Likelihood that this image contains violent content. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. float getRacyLikelihood( ) Likelihood that the request image contains racy content. 0.1 - very unlikely; 0.3 - unlikely; 0.5 - possible; 0.7 - likely; 0.9 - very likely. Crop Hints Response com.google.firebase.ml.vision.cloud.crophints class FirebaseVisionCloudCropHint Represents the cloud vision corp hints detector @Nullable Gets image region of the crop hint. Rect getBoundingBox( ) float getConfidence( ) Gets overall confidence confidence of the result. Range [0, 1]. float getImportanceFraction( ) Gets fraction of importance of this salient region with respect to the original image. Range [0, 1] iOS¹: ¹Unless explicitly indicated otherwise, all iOS APIs assume nonnull wherever applicable.

Common Classes Class API Reference Source FIRVision header (added cloud*Detector and cloud*DetectorWithOptions: methods) FIRVisionCloudDetectorOptions header FIRVisionImageMetadata header FIRVisionLatitudeLongitude header Detectors Class API Reference Source FIRVisionCloudDocumentTextDetector header FRVisionCloudLabelDetector header FIRVisionCloudLandmarkDetector header FIRVisionCloudTextDetector header Features Class API Reference Source FIRVisionPoint header FIVisionCloudLabelFeature header FIRVisionCloidLandmarkFeature header FIRVisionCloudTextFeature header FIRVisionCloudPage header FIRVisionCloudBlock header FIRVisionCloudParagraph header FIRVisionCloudWord header FIRVisionCloudSymbol header FIRVisionCloudTextProperty header FIRVisionCloudDetectedBreak header FIRVisionCloudDetecedLanguage header

APPENDIX C Android Face detector // Define the options for detector. FirebaseVisionFaceDetectorOptions detectorOptions = new FirebaseVisionFaceDetectorOptions.Builder( ) .setLandmark(FirebaseVisionFaceDetectorOptions.ALL_LANDMARKS).build( ); // Get an instance of FirebaseVisionFaceDetector. FirebaseVisionFaceDetector detector = FirebaseVision.getInstance( ) .getFaceDetector(detectorOptions); // Specify the metadata for the input image. FirebaseVisionImageMetadata metadata = FirebaseVisionImageMetadata.newBuilder( ) .setWidth(640).setHeight(480).setRotation(Rotation.Rotation_0) .setFormat(ImageFormat.IMAGE_FORMAT_NV21).build( ); // Detect face in the image with listeners. Task<List<FirebaseVisionFace>> result = detector.detect(FirebaseVisionImage.fromByteBuffer(bytebuffer, metadata)) .addOnSuccessListener( this, /** Activity */ new OnSuccessListener( ) { @Override void onSuccess(List<FirebaseVisionFace> faces) { for (int i = 0; i < faces.size( ); ++i) { int key = faces.keyAt(i); FirebaseVisionFace face = faces.get(key); Log.i(TAG, “face center position X: ” + face.getBoundingBox( ).centerX( )); Log.i(TAG, “face center position Y: ” + face.getBoundingBox( ).centerY( )); } }}) .addOnFailureListener( this, /** Activity */ new OnFailureListener( ) { @Override void onFailure(Throwable t) { ... } }); Barcode detector // Get an instance of FirebaseVisionBarcodeDetector. FirebaseVisionBarcodeDetector detector = FirebaseVision.getInstance( ) .getBarcodeDetector( ); // Specify the metadata for the input image. FirebaseVisionImageMetadata metadata - FirebaseVisionImageMetadata.newBuilder( ) .setWidth(640).setHeight(480).setRotation(Rotation.Rotation_0) .setFormat(ImageFormat.IMAGE_FORMAT_NV21).build( ); // Get the bytebuffer from camera. ByteBuffer byteBuffer = ... // Detect the barcodes inside the image. Task<List<FirebaseVisionBarcodeBlock>> result = detector.detect (FirebaseVisionImage.fromByteBuffer(bytebuffer, metadata)) .addOnCompleteListener( this, /** Activity */ new OnCompleteListener( ) { @Override void onComplete(Task<List<FirebaseVisionBarcode>> task) { try { List<FirebaseVisionBarcode> barCodes =task.getResult(FirebaseMLException.class); for (int i = 0.; i < barCodes.size( ); i++) { FirebaseVisionBarcode barCode = barCodes.valueAt(i); // Use the recognized bar code in your app. Log.i(“TAG”, “Recognized barcode raw value ” + barCode.rawValue); // Developers can configure a few types of barcodes that they can handle. int valueType = barCode.valueType; if (valueType == FirebaseVisionBarcode.CONTACT_INFO) { FirebaseVisionBarcode.ContactInfo contactInfo = FirebaseVisionBarcode.contactInfo; } if (contactInfo.emails != null && contactInfo.emails.length > 0) { Log.i(“TAG”, “Email: ” + contactInfo.emails[0].address); } } } catch (FirebaseMLException e) { // Exception handling } }); Text detector // Get an instance of FirebaseVisionTextDetector. FirebaseVisionTextDetector detector = FirebaseVision.getInstance( ).getTextDetector( ); // Specify the metadata for the input image. FirebaseVisionImageMetadata metadata = FirebaseVisionImageMetadata.newBuilder( ) .setWidth(640).setHeight(480).setRotation(Rotation.Rotation_0) .setFormat(ImageFormat.IMAGE_FORMAT_NV21).build( ); // Get the bytebuffer from somewhere. ByteBuffer byteBuffer = ... // Detect the texts inside the image. Task<List<FirebaseVisionTextBlock>> result = detector.detect(FirebaseVisionImage.fromByteBuffer(bytebuffer, metadata)) .addOnSuccessListener( this, /** Activity */ new OnSuccessListener( ) { @Override void onSuccess(List<FirebaseVisionTextBlock> texts) { for (int i = 0; i < texts.size( ); i++) { FirebaseVisionTextBlock block = texts.valueAt(i); Log.i(“TAG”, “Recognized text ” + block.getRecognizedText( )); // Print out the components (lines, or words) in the text. List<FirebaseVisionTextLine> lines = block.getComponents( ); for (FirebaseVisionTextLine line : lines) { Log.i(“TAG”, “Recognized line ” + line.getRecognizedText( )); List<FirebaseVisionTextElement> words = line.getComponents( ); for (FirebaseVisionTextElement word : words) { Log.i(“TAG”. “Recognized word ” + word.getRecognizedText( )); }}}} }) .addOnFailureListener( this, /** Activity */ new OnFailureListener( ) { @Override void onFailure(Exception e) { ... } }); iOS

Face detector Objective-C: // Get the instance of the ‘FIRVision’ for the default ‘FIRApp’. FIRVision *mlVision = [FIRVision vision]; // Define the options for a face detector. FIRVisionFaceDetectorOptions *faceDetectorOptions = [[FIRVisionFaceDetectorOptions alloc] init]; faceDetectorOptions.landmarkType = FIRVisionFaceDetectorLandmarkAll; // Get an instance of ‘FIRVisionFaceDetector’ . FIRVisionFaceDetector faceDetector = [mlVision faceDetectorWithOptions:faceDetectorOptions]; // Define the metadata of the image for detection. FIRVisionImageMetadata *imageMetadata = [[FIRVisionImageMetadata alloc] init]; imageMetadata.orientation = FIRVisionDetectorImageOrientationTopLeft; // Define the FIRVisionImage for detection. FIRVisionImage *image = [[FIRVisionImage alloc] initWithImage:self.faceImageView.image metadata:imageMetadata]; // Invoke face detection in the image. FIRVisionFaceDetectionCallback completion = {circumflex over ( )}(( NSArray<FIRVisionFaceFeature *> * _Nullable features, NSError * _Nullable error) { if (error != nil) { // Handle the error. NSLog(@“Face detection error: %@”, error.localizedDescription); } else { // TODO: Build the coolest feature using the returned features in ‘features’. } }; [faceDetector detectInImage:image completion:completion]; Swift: // Get the instance of the ‘Vision’ for the default ‘FirebaseApp’. let mlVision = Vision.vision( ) // Define the options for a face detector. let faceDetectorOptions = VisionFaceDetectorOptions( ) faceDetectorOptions.landmarkType = .all // Get an instance of ‘VisionFaceDetector’. let faceDetector = mlVision.faceDetector(options: faceDetectorOptions) // Define the metadata of the image for detection. let imageMetadata = VisionImageMetadata( ) imageMetadata.orientation = .topLeft // Define the VisionImage for detection. let visionImage = VisionImage (image: image!, metadata: imageMetadata) // Invoke face detection in the image. faceDetector.detect(image: image, completion: { (features: [VisionFaceFeature]?, error: Error?) in if error != nil { // TODO: Build the coolest, feature using the returned features in ‘features’. } else { fatalError(“Face detection error”); } }) Barcode detector Objective-C: // Get the instance of the ‘FIRVision’ for the default ‘FIRApp’. FIRVision *mlVision = [FIRVision vision]; // Define the options for a barcode detector. FIRVisionBarcodeDetectorOptions *barcodeDetectorOptions = [[FIRVisionBarcodeDetectorOptions alloc] init]; barcodeDetectorOptions.format = FIRVisionBarcodeFormatQRCode | FIRVisionBarcodeFormatCodaBar; // Get an instance of ‘FIRVisionBarcodeDetector’. FIRVisionBarcodeDetector barcodeDetector = [mlVision barcodeDetectorWithOptions:barcodeDetectorOptions]; // Define the metadata of the image for detection. FIRVisionImageMetadata *imageMetadata = [[FIRVisionImageMetadata alloc] init]; imageMetadata.orientation = FIRVisionDetectorImageOrientationTopLeft; // Define the FIRVisionImage for detection. FIRVisionImage *visionimage = [[FIRVisionlmage alloc] initWithImage:image metadata:imageMetadata]; // Invoke barcode detection in the image. FIRVisionBarcodeDetectionCallback completion = {circumflex over ( )}(( NSArray<FIRVisionBarcodeFeature *> * _Nullable features, NSError * _Nullable error) { if (error != nil) { // Handle the error. NSLog(@“Barcode detection error: %@”, error.localizedDescription); } else { // TODO: Build the coolest feature using the returned features in ‘features’. } }; [barcodeDetector detectInImage:image completion:completion]; Swift: // Get an image to recognize the barcode on. let image = UIImage(named: “someImage.png”) // Machine learning instance creation let mlVision = Vision.vision( ) // Define the options for a barcode detector. let barcodeOptions : VisionBarcodeDetectorOptions = VisionBarcodeDetectorOptions( ) barcodeOptions.format = .qrCode | .codaBar let barcodeDetector = mlVision.barcodeDetector(options: barcodeOptions) // Define the metadata of the image for detection. let imageMetadata : VisionImageMetadata = VisionImageMetadata( ) imageMetadata.orientation = .topLeft // Define the VisionImage for detection. let visionImage = VisionImage(image: image!, metadata: imageMetadata) // Invoke barcode detection in the image. barcodeDetector.detect(image: image, completion: { (features: [VisionBarcodeFeature]?, error: Error?) in if error != nil { // Go through the array of barcode features to process them as desired. features!.forEach({ (mlFeature: VisionBarcodeFeature) in // Process barcode feature as desired here }) } else { fatalError(“Barcode detection error”); } } Text detector Objective-C: // Get an image to recognize the text on. UImage *image = [UIImage imageNamed:@“someImage.png”]; // Get the instance of the ‘FIRVision’ for the default ‘FIRApp’. FIRVision *mlVision = [FIRVision vision]; // Get the instance of text detector, FIRVisionTextDetector *textDetector = [mlVision textDetectorWithError:&detectorError]; // Define the FIRVisionImage for detection. FIRVisionImage *visionImage = [[FIRVisionImage alloc] initWithImage:image metadata:nil]; // Run detect for the image and get an array of text features. FIRVisionTextDetectionCallback completion = {circumflex over ( )}(( NSArray<FIRVisionTextFeature *> * _Nullable features. NSError * _Nullable error) { if (error != nil) { // Handle the error. NSLog(@“Text detection error: %@”, error.localizedDescription); } else { // Go through the array of text features to process them as desired. for (id <FIRVisionTextFeature> text in texts) { if ([text isKindOfClass:[FIRVisionTextBlockFeature class]]) { FIRVisionTextBlockFeature *block = (FIRVisionTextBlockFeature *)text; NSLog(@“The text in the frame:%@.\n”, NSStringFromCGRect(block.frame)); for (FIRVisionTextLineFeature *line in block.lines) { NSLog(@“%@\n”, line.recognizedText); for (FIRVisionTextElementFeature *element in line.elements) { // Process elements features here. } } } } }; [faceDetector detectInImage:image completion:completion]; Swift: // Get an image to recognize the text on. let image = UIImage(named: “sameImage.png”) let mlFeatures: [VisionTextFeature] // Machine learning instance creation let mlVision = Vision.vision( ) // Get the instance of text detector. let textDetector = mlVision.textDetector( ) // Define the metadata of the image for detection. let imageMetadata : VisionImageMetadata = VisionImageMetadafa( ) imageMetadata.orientation = .topLeft // Define the VisionImage for detection. let visionImage = VisionImage(image: image!, metadata: nil) // Invoke text detection in the image. textDetector.detect(image: image, completion: { (features: [VisionTextFeature]?, error: Error?) in if error != nil { // Go through the array of text features to process them as desired. features!.forEach({ (mlFeature: VisionTextFeature) in // Process text feature as desired here }) } else { fatalError(“Text detection error”); } }

Change Details New API Signatures

Andriod Common Classes com.google.firebase.ml.vision Class FirebaseVision Represent the firebase vision service. static FirebaseVision getInstance( ) Get the instance of Firebase vision static FirebaseVision getInstance(@NonNull Get an instance of Firebase vision for an given FirebaseApp FirebaseApp app) FirebaseVisionFaceDetector getFaceDetector( Get an instance of this face detector with a given option. @NonNull FirebaseVisionFaceDetectorOptions option) (Note: it always returns a new face detector instance. However, if two detector are created with the same options, they share the same model instance and use reference count to manage the mode lifecycle.) FirebaseVisionFaceDetector getFaceDetector( ) Same with above with default option. FirebaseVisionTextDetector getTextDetector( ) Get an instance of text detector. The returned instance is a singleton. (Note: it always returns a new text detector instance. However, they share the same model instance and use reference count to manage the mode lifecycle.) FirebaseVisionBarcodeDetector getBarcodeDetector( Get an instance of barcode detector with an option @NonNull FirebaseVisionBarcodeDetectorOptions) configuring what formats of barcode are supported. (Note: it always returns a new barcode detector instance. However, if two detector are created with the same options, they share the same model instance and use reference count to manage the mode lifecycle.) FirebaseVisionBarcodeDetector getBarcodeDetector( ) Same with above with default option. com.google.firebase.ml.vision Class FirebaseVisionImage Represents an image. (static) FirebaseVisionImage fromBitmap( Create Image from a Bitmap with image metadata. @Nonnull Bitmap image, (Only image orientation is needed.) @Nonnull FirebaseVisionImageMetadata metadata); (static) FirebaseVisionImage fromBitmap( Same with above with default option. @Nonnnull Bitmap image) (static) FirebaseVisionImage fromByteBuffer( Create image from a byte buffer with image metadata. @Nonnull ByteBuffer buffer, (Image width, height, format, orientation are needed.) @Nonnull FirebaseVisionImageMetadata metadata); (static) FirebaseVisionImage fromByteBuffer( Same with above with default option. @Nonnnull ByteBuffer buffer) (static) FirebaseVisionImage fromBytes( Create image from a byte array with image metadata. @Nonnull byte[ ] bytes, (Image width, height, format, orientation are needed.) @Nonnull FirebaseVisionImageMetadata metadata); (static) FirebaseVisionImage fromBytes( Same with above with default option. @Nonnnull byte[ ] bytes) (static) FirebaseVisionImage fromFilePath( Same with above with default option. @Nonnnull String imageFilePath) com.google.firebase.ml.vision class FirebaseVisionImageMetadata Metadata for an given image. @IntDef({ Rotation types. ROTATION_0, ROTATION_90, ROTATION_180, ROTATION_270, ROTATION_FLIP_0, ROTATION_FLIP_90, ROTATION_FLIP_180, ROTATION_FLIP_270 }) public @interface Rotation { } @IntDef({ Image Format IMAGE_FORMAT_NV16, IMAGE_FORMAT_NV21, IMAGE_FORMAT_YV12, }) public @interface ImageFormat { } FirebaseVisionImageMetadata( Copy the metadata @Nonnull FirebaseVisionImageMetadata metadata); int getWidth( ); Get width of an image int getHeight( ); Get height of an image @Rotation int getRotation( ); Get rotation of the image. Default to ROTATION_. @ImageFormat int getFormat( ); Get image format. Default to IMAGE_FORMAT_NV21 Builder builder( ); Builder pattern to set all the features above. com.google.firebase.ml.vision class FirebaseVisionImageMetadata.Builder Image metadata Builder. Builder setWidth(int width) Set width Builder setHeight(int height); Set height of an image Builder setRotation(@Rotation int rotation); Set rotation of the image Builder setFormat(@ImageFormat int format); Set image format. FirebaseVisionImageMetadata build( ); Build an image metadata Face Detection API com.google.firebase.ml.vision.face class FirebaseVisionFaceDetector implements Closeable Provides methods for detect human faces. Task<List<FirebaseVisionFace> detect(@Nonnull FirebaseVisionImage Detect face features in image. image); com.google.firebase.ml.vision.face class FirebaseVisionFace Represents a human face. RectF getBoundingBox( ) The rectangle that holds the discovered feature relative to the detected image in the view coordinate system. @Nullable The tracking identifier of the feature. Integer getTrackingId( ) @Nullable Indicates the rotation of the face about the vertical axis of the Float getHeadEulerAngleY( ); image. Positive euler y is when the face is turned towards the right side of the image that is being processed. @Nullable Indicates the rotation of the face about the axis pointing out of the Float getHeadEulerAngleZ( ); image. Positive euler z is a counter-clockwise rotation within the image plane. @Nullable PointF getBottomMouthPosition( ); The coordinates of the bottom lip center, relative to the detected image in the view coordinate system. @Nullable PointF getRightMouthPosition( ); The coordinates of the right mouth corner, relative to the detected image in the view coordinate system. @Nullable PointF getLeftMouthPosition( ); The coordinates of the left mouth corner, relative to the detected image in the view coordinate system. @Nullable PointF getLeftEarPosition( ); The coordinates of the midpoint between the face's midpoint of the left ear tip and left ear lobe, relative to the detected image in the view coordinate system. @Nullable PointF getRightEarPosition( ); The coordinates of the midpoint between the face's midpoint of the right ear tip and right ear lobe, relative to the detected image in the view coordinate system. @Nullable PointF getLeftEyePosition( ); The coordinates of the left eye, relative to the detected image in the view coordinate system. @Nullable PointF getRightEyePosition( ); The coordinates of the right eye, relative to the detected image in the view coordinate system. @Nullable PointF getLeftCheekPosition( ); The coordinates of the left cheek, relative to the detected image in the view coordinate system. @Nullable PointF getRightCheekPosition( ); The coordinates of the right cheek, relative to the detected image in the view coordinate system. @Nullable PointF getNoseBasePosition( ); The coordinates of the midpoint between the nostrils, relative to the detected image in the view coordinate system. @Nullable Probability that the face is smiling. Float getSmilingProbability( ); @Nullable Probability that the face's left eye is open. Float getLeftEyeOpenProbability( ); @Nullable Probability that the face's right eye is open. Float getRightEyeOpenProbability( ); com.google.firebase.ml.vision.face class FirebaseVisionFaceDetectorOptions Config options for face detector. @IntDef({ Indicates whether to run additional classifiers for characterizing NO_CLASSIFICATIONS, ALL_CLASSIFICATIONS, attributes such as “smiling” and “eyes open”. }) public @interface Classification { } @IntDef({ Extended option for controlling additional accuracy/speed FAST_MODE, ACCURATE_MODE, trade-offs in performing face detection. In general, choosing the }) more accurate mode will generally result in longer runtime, whereas public @interface Mode { } choosing the faster mode will generally result in detecting fewer faces. @IntDef({ Sets whether to detect no landmarks or all landmarks. Processing NO_LANDMARKS, ALL_LANDMARKS, time increases as the number of landmarks to search for increases, }) so detecting all landmarks will increase the overall detection time. public @interface Landmark { } Detecting landmarks can improve pose estimation. @Landmark Set type of landmark detection, default is NO_LANDMARK for lower int getLandmark( ); latency. @Classificatoin Whether to detect additional attributes, like smiling. Default is no int getClassification( ): attribute. boolean getTrackingEnabled( ); Whether to track same face in consecutive images. Default is false. @Model Choose accuracy or speed. Default is for speed. int getMode( ); float getMinFaceSize( ); Sets the minimal face ratio to detect based on image's width. com.google.firebase.ml.vision.face class FirebaseVisionFaceDetectorOptions.Builder Builder of config options for face detector. Builder setLandmark(@Landmark int landmark); Set type of landmark detection. default is NO_LANDMARK for lower latency. Builder setClassification(@Classification int Whether to detect additional attributes, like smiling. Default is classification) no attribute. Builder setTrackingEnabled(boolean Whether to track same face in consecutive images. Default is trackingEnabled) NO. Builder setMode(@Model int mode) Choose accuracy or speed. Default is for speed. Builder setMinFaceSize(float Sets the minimal face ratio to detect based on image's width. proportionalMinFaceSize) FirebaseVisionFaceDetectorOptions build( ) Build FirebaseVisionFaceDetectorOptions. Barcode Detection API com.google.firebase.ml.vision.barcode class FirebaseVisionBarcodeDetector implements Closeable Provides methods for detect barcode Task<List<FirebaseVisionBarcode> detect(@Nonnull Detect Barcodes in image. FirebaseVisionImage image); com.google.firebase.ml.vision.barcode class FirebaseVisionBarcodeDetectorOptions.Builder Represent the barcode API options builder class Builder setBarcodeFormats(@BarcodeFormat int format, Sets all supported barcode formats, e.g. @BarcodeFormat int... moreFormats) .setBarcodeFormats(Barcode.DATA_MATRIX, Barcode.QR_CODE). Reducing the number of supported formats can make the barcode detector faster. FirebaseVisionBarcodeDetector build( ) Gets a built-out FirebaseVisionBarcodeDetector com.google.firebase.ml.vision.barcode class FirebaseVisionBarcodeDetectorOptions Represent the barcode API options class com.google.firebase.ml.vision.barcode class FirebaseVisionBarcode Represents a barcode object. @IntDef({ Supported barcode format enum definition. FORMAT_UNKNOWN, FORMAT_ALL_FORMATS, FORMAT_CODE_128, FORMAT_CODE_39, FORMAT_CODE_93, FORMAT_CODABAR, FORMAT_DATA_MATRIX, FORMAT_EAN_13, FORMAT_EAN_8, FORMAT_ITF, FORMAT_QR_CODE, FORMAT_UPC_A, FORMAT_UPC_E, FORMAT_PDF417, FORMAT_AZTEC }) public @interface BarcodeFormat { } @IntDef({ Format of the barcode value. Developers TYPE_UNKNOWN, TYPE_CONTACT_INFO, TYPE_EMAIL, can sometimes get extra concrete classes for further parsed barcode value like TYPE_ISBN, TYPE_PHONE, TYPE_PRODUCT, CALENDAR_EVENT/ TYPE_SMS, TYPE_TEXT, TYPE_URL, CONTACT_INFO . . . (but not all TYPE_WIFI, TYPE_GEO, TYPE_CALENDAR_EVENT, types have extended information, e.g. TYPE_DRIVER_LICENSE ISBN, PRODUCT, TEXT won't have }) further parsed information other than public @interface BarcodeValueType { } getRawValue( )) Rect getBoundingBox( ) Gets the axis-aligned bounding box of the detected barcode. PointF[ ] getCornerPoints( ) Four comer points in clockwise direction starting with top-left. @Nullable String getDisplayValue( ) Retrieve the barcode value in a user- friendly format @BarcodeFormat int getFormat( ) Barcode format, for example EAN_13 @Nullable String getRawValue( ) Barcode value as it was encoded in the barcode. @BarcodeValueType int getValueType( ) Format of the barcode value, e.g. TEXT, PRODUCT, URL . . . Note that this field may contain values not present in the current set of value format constants. When mapping this value to something else, it is advisable to have a default/fallback case. Below getter methods return further parsed out information of the barCode, all are Nullable. @Nullable CalendarEvent getCalendarEvent( ) Parsed calendar event details (set iff valueType is CALENDAR_EVENT). @Nullable ContactInfo getContactInfo( ) Parsed contact details (set iff valueType is CONTACT_INFO). @Nullable DriverLicense getDriverLicense( ) Parsed driver's license details (set iff valueType is DRIVER_LICENSE). @Nullable Email getEmail( ) Parsed email details (set iff valueType is EMAIL). @Nullable GeoPoint getGeoPoint( ) Parsed geo coordinates (set iff valueType is GEO). @Nullable Phone getPhone( ) Parsed phone details (set iff valueType is PHONE). @Nullable Sms getSms( ) Parsed SMS details (set iff valueType is SMS). @Nullable UrlBookmark getUrl( ) Parsed URL bookmark details (set iff valueType is URL). @Nullable WiFi getWiFi( ) Parsed WiFi AP details (set iff valueType is WIFI). com.google.firebase.ml.vision.barcode Nested classes inside FirebaseVisionBarcode (Note that these are replications of nested classes under com.google.android.gms.vision.barcode.Barcode and clicking the link to find detailed fields. And in our version of API, getter methods like getEmail( ) will be exposed instead of public-fields) FirebaseVisionBarcode.Address An address. (used by ContactInfo) FirebaseVisionBarcode.CalendarDateTime DateTime data type used in calendar events. (used by CalendarEvent) FirebaseVisionBarcode.CalendarEvent A calendar event extracted from QRCode. (CALENDAR_EVENT type) FirebaseVisionBarcode. DriverLicense A driver license or ID card. This is for US only. (DRIVER_LICENSE type) FirebaseVisionBarcode.ContactInfo A person's or organization's business card. (CONTACT_INFO type) FirebaseVisionBarcode.Email An email message from a ‘MAILTO:’ or similar QRCode type. (EMAIL type, also used by ContactInfo) FirebaseVisionBarcode.GeoPoint GPS coordinates from a ‘GEO:’ or similar QRCode type. (GEO type) FirebsaeVisionBarcode.PersonName A person's name, both formatted version and individual name (used by ContactInfo) components. FirebaseVisionBarcode.Phone A phone number from a ‘TEL:’ or similar QRCode type. (PHONE type) FirebaseVisionBarcode.Sms An sms message from an ‘SMS:’ or similar QRCode type. (SMS type) FirebaseVisionBarcode.UrlBookmark A URL and title from a ‘MEBKM:’ or similar QRCode type. (URL type) FirebaseVisionBarcode.WiFi A wifi network parameters from a ‘WIFI:’ or similar QRCode (WIFI type) type. Text Detector API com.google.firebase.ml.vision.text class FirebaseVisionTextDetector implements Closeable Provides methods for detect texts. Task<List<FirebaseVisionTextBlock> detect(@Nonnull Detect texts in image. FirebaseVisionImage image); com.google.firebase.ml.vision.text interface FirebaseVisionText Represents a piece of text. It can be a paragraph, a line or a word. Interface methods definitions omitted RectF getBoundingBox( ) The rectangle that holds the discovered feature relative to the detected image in the view coordinate system. PointF[ ] getCornerPoints( ) Four corner points in clockwise direction starting with top-left. The points are in the frame's coordinations system after applying the rotation. Special note when the camera is facing front (i.e. using the selfie camera): the origin point of the frame will be the top right corner. And the returned four corner points will be in counter clockwise direction starting with top-right. String getRecognizedText( ) Retrieve the recognized text as a string. com.google.firebase.ml.vision.text class FirebaseVisionTextBlock implements FirebaseVisionText Represents a text block, i.e. a paragraph. Interface methods definitions omitted. Does not introduce new methods on top of FirebaseVisionText. List<FirebaseVisionTextLine> getLines( ) Gets the components (i.e. a list of lines) inside this text block. com.google.firebase.ml.vision.text class FirebaseVisionTextLine implements FirebaseVisionText Represents a line of text. Interface methods definitions omitted. Does not introduce new methods on top of FirebaseVisionText. List<FirebaseVisionTextElement> getElements( ) Gets the components (i.e. a list of words) inside this line. com.google.firebase.ml.vision.text class FirebaseVisionTextElement implements FirebaseVisionText Represents an element, i.e. a word in latin languages or a character in others. interface methods definitions omitted. Does not introduce new methods on top of FirebaseVisionText. iOS¹ ¹ Unless explicitly indicated otherwise, all iOS APIs assume nonnull wherever applicable.

Common Classes NS_SWIFT_NAME(Vision) @interface FIRVision: NSObject A Firebase service that supports machine learning vision tasks on iOS. + (instancetype)vision NS_SWIFT_NAME(vision( )) Gets an instance of Firebase Vision service for the default Firebase app. This method is thread safe. The default Firebase app instance must be configured before calling this method; otherwise raises FIRAppNotConfigured exception. + (instancetype)visionForApp:(FIRApp *)app NS_SWIFT_NAME(vision(app:)) Gets an instance of Firebase Vision service for the custom Firebase app. This method is thread safe. − (FIRVisionFaceDetector *) Gets a face detector with the given faceDetectorWithOptions:(FIRVisionFaceDetectorOptions *)options options. The returned detector is not NS_SWIFT_NAME(faceDetector(options:)) thread safe. − (FIRVisionFaceDetector *)faceDetector NS_SWIFT_NAME(faceDetector( )) Same as above with default options − (FIRVisionBarcodeDetector *) Gets a barcode detector with the given barcodeDetectorWithOptions:(FIRVisionBarcodeDetectorOptions *)options options. The returned defector is not NS_SWIFT_NAME(barcodeDetector(options:)) thread safe. − (FIRVisionBarcodeDetector *)barcodeDetector Same as above with default options NS_SWIFT_NAME(barcodeDetector( )) − (FIRVisionTextDetector *)textDetector NS_SWIFT_NAME(textDetector( )) Gets a text detector. The returned detector is not thread safe. NS_SWIFT_NAME(VisionImageMetadata) @interface FIRVisionImageMetadata: NSObject Metadata of an image used in feature detection. @property(nonatomic) The display orientation of the image. Defaults to FIRVisionDetectorImageOrientation orientation VisionDetectorImageOrientationTopLeft. typedef NS_ENUM(NSUInteger, This enum specifies where the origin (0, 0) of the image is FIRVisionDetectorImageOrientation) { located. The constant has the same value as defined by EXIF FIRVisionDetectorImageOrientationTopLeft = 1, specifications. FIRVisionDetectorImageOrientationTopRight, (Rotation detailed meaning) FIRVisionDetectorImageOrientationBottomRight, FIRVisionDetectorImageOrientationBottomLeft, FIRVisionDetectorImageOrientationLeftTop, FIRVisionDetectorImageOrientationRightTop, FIRVisionDetectorImageOrientationRightBottom, FIRVisionDetectorImageOrientationLeftBottom } NS_SWIFT_NAME(VisionDetectorImageOrientation) NS_SWIFT_NAME(VisionImage) @interface FIRVisionImage: NSObject An image or image buffer used in vision detection. @property(nonatomic, nullable) FIRVisionImageMetadata *metadata Metadata about the image (e.g. image orientation). If metadata is not specified, the default metadata values are used. − (instancetype)initWithImage:(UIImage *)image Same with above with default metadata − (instancetype)initWithSampleBuffer:(CMSampleBufferRef)sampleBuffer Same with above with default metadata Face Detection API NS_SWIFT_NAME(VisionFaceDetector) @interface FIRVisionFaceDetector: NSObject A face detector that searches for and identifies notable facial features in a still image or video. typedef void ({circumflex over ( )}FIRVisionFaceDetectionCallback)( The callback to invoke when the face detection NSArray<FIRVisionFaceFeature *> * _Nullable features, completes. NSError * _Nullable error) NS_SWIFT_NAME(VisionFaceDetectionCallback) − (void)detectInImage:(FIRVisionImage *)image Searches for facial features in an image. The completion:(FIRVisionFaceDetectionCallback)completion completion callback will be invoked on the main thread. NS_SWIFT_NAME(VisionFaceDetectorOptions) @interface FIRVisionFaceDetectorOptions: NSObject Options for specifying a face detector. @property(nonatomic) FIRVisionFaceDetectorClassification Whether to run additional classifiers for characterizing classification attributes such as smiling. Defaults to VisionFaceDetectorClassificationNone. @property(nonatomic) FIRVisionFaceDetectorMode modeType Preference for accuracy vs. speed trade-offs in face detection. Defaults to VisionFaceDetectorModeFast. @property(nonatomic) FIRVisionFaceDetectorLandmark Whether to detect no landmarks or all landmarks in face landmarkType detection. Processing time increases as the number of landmarks to search for increases, so detecting all landmarks will increase the overall detection time. Defaults to VisionFaceDetectorLandmarkNone. @property(nonatomic) CGFloat minFaceSize The smallest desired face size. The size is expressed as a proportion of the width of the head to the image width. For example, if a value of 0.1 is specified, then the smallest face to search for is roughly 10% of the width of the image being searched. Defaults to VisionFaceDetectionMinSize. @property(nonatomic) BOOL isTrackingEnabled Whether the face tracking feature is enabled in face detection. Defaults to NO. extern const CGFloat FIRVisionFaceDetectionMinSize Default smallest desired face size: 0.1. NS_SWIFT_NAME(VisionFaceDetectionMinSize) typedef NS_ENUM(NSUInteger, This enum specifies the classification type in face FIRVisionFaceDetectorClassification) { detection. FIRVisionFaceDetectorClassificationNone = 1, FIRVisionFaceDetectorClassificationAll, } NS_SWIFT_NAME(VisionFaceDetectorClassification) typedef NS_ENUM(NSUInteger, FIRVisionFaceDetectorMode) { This enum specifies a preference for accuracy vs, FIRVisionFaceDetectorModeFast = 1, speed trade-offs in face detection. FIRVisionFaceDetectorModeAccurate, } NS_SWIFT_NAME(VisionFaceDetectorMode) typedef NS_ENUM(NSUInteger, FIRVisionFaceDetectorLandmark) { This enum specifies the landmark detection type in face FIRVisionFaceDetectorLandmarkNone = 1, detection. FIRVisionFaceDetectorLandmarkAll, } NS_SWIFT_NAME(VisionFaceDetectorLandmark) NS_SWIFT_NAME(VisionPoint) @interface FIRVisionPoint : NSObject A 2D or 3D point in the image. A valid point must have both x and y coordinates. The points * coordinates are in the same scale as the original image. @property(nonatomic, readonly) NSNumber *x X coordinate. The value is float. @property(nonatomic, readonly) NSNumber *y Y coordinate. The value is float. @property(nonatomic, readonly, nullable) NSNumber *z Z coordinate (or depth). The value is float. Z is nil if it is a 2D point. − (instancetype)init NS_UNAVAILABLE NS_SWIFT_NAME(VisionFaceLandmark) @interface FIRVisionFaceLandmark: MSObject A landmark on a human face detected in an image. @property(nonatomic, readonly) FIRFaceLandmarkType type The type of the facial landmark. @property(nonatomic, readonly) FIRVisionPoint *position 2D position of the facial landmark. − (instancetype)init NS_UNAVAILABLE typedef NSString *FIRFaceLandmarkType Type of all facical landmarks. NS_EXTENSIBLE_STRING_ENUM NS_SWIFT_NAME(FaceLandmarkType) extern FIRFaceLandmarkType const Center of the bottom lip. FIRFaceLandmarkTypeMouthBottom extern FIRFaceLandmarkType const Right comer of the mouth FIRFaceLandmarkTypeMouthRight extern FIRFaceLandmarkType const Left comer of the mouth FIRFaceLandmarkTypeMouthLeft extern FIRFaceLandmarkType const FIRFaceLandmarkTypeLeftEar Midpoint of the left ear tip and left ear lobe. extern FIRFaceLandmarkType const FIRFaceLandmarkTypeRightEar Midpoint of the right ear tip and right ear lobe. extern FIRFaceLandmarkType const FIRFaceLandmarkTypeLeftEye Left eye. extern FIRFaceLandmarkType const FIRFaceLandmarkTypeRightEye Right eye. extern FIRFaceLandmarkType const Left cheek. FIRFaceLandmarkTypeLeftCheek extern FIRFaceLandmarkType const Right cheek. FIRFaceLandmarkTypeRightCheek extern FIRFaceLandmarkType const FIRFaceLandmarkTypeNoseBase Midpoint between the nostrils where the nose meets the face. NS_SWIFT_NAME(VisionFaceFeature) @interface FIRVisionFaceFeature: NSObject A human face feature detected in an image. @property(nonatomic, readonly) CGRect frame The rectangle that holds the discovered feature relative to the detected image in the view coordinate system. @property(nonatomic, readonly) BOOL hasTrackingID Indicates whether the feature has a tracking ID. @property(nonatornic, readonly) NSUInteger trackingID The tracking identifier of the feature. @property(nonatomic, readonly) BOOL hasHeadEulerAngleY Indicates whether the detector found the head y euler angle. @property(nonatomic, readonly) CGFloat headEulerAngleY Indicates the rotation of the face about the vertical axis of the image. Positive euler y is when the face is turned towards the right side of the image that is being processed. @property(nonatomic, readonly) BOOL hasHeadEulerAngleZ Indicates whether the detector found the head z euler angle. @property(nonatomic, readonly) CGFloat headEulerAngleZ Indicates the rotation of the face about the axis pointing out of the image. Positive euler z is a counter-clockwise rotation within the image plane. @property(nonatomic, readonly) BOOL hasSmilingProbability Indicates whether a smiling probability is available. @property(nonatomic, readonly) CGFloat smilingProbability Probability that the face is smiling. @property(nonatomic, readonly) BOOL Indicates whether a left eye open probability is available. hasLeftEyeOpenProbability @property(nonatomic, readonly) CGFloa t Probability that the face's left eye is open. leftEyeOpenProbability @property(nonatomic, readonly) BOOL Indicates whether a right eye open probability is available. hasRightEyeOpenProbability @property(nonatomic, readonly) CGFloat Probability that the face's right eye is open. rightEyeOpenProbability − (nullable FIRVisionFaceLandmark *) Returns the landmark, if any, of the given type in this landmarkOfType:(FIRFaceLandmarkType)type detected face. Barcode Detection API NS_SWIFT_NAME(VisionBarcodeDetector) @interface FIRVisionBarcodeDetector: NSObject A barcode detector that recognizes barcode and extracts info in an image. typedef void ({circumflex over ( )}FIRVisionBarcodeDetectionCallback)( The callback to invoke when the barcode NSArray<FIRVisionBarcodeFeature *> * _Nullable features, detection completes. NSError * _Nullable error) NS_SWIFT_NAME(VisionBarcodeDetectionCallback) − (void)detectInImage:(FIRVisionImage *)image Searches for barcode features in an image. completion:(FIRVisionBarcodeDetectionCallback)completion The completion callback will be invoked on the main thread. NS_SWIFT_NAME(VisionBarcodeDetectorOptions) @interface FIRVisionBarcodeDetectorOptions: NSObject An options to config Firebase Barcode detector. − (instancetype)init Initializes the instance with all formats, which may slow the executions. − (instancetype)initWithFormats:(FIRVisionBarcodeFormat)formats Initializes the instance with interested formats. @property(nonatomic, readonly) FIRVisionBarcodeFormat format Set interested Barcode formats in barcode detector. typedef NS_OPTIONS(NSInteger, FIRVisionBarcodeFormat) { This option specifies the barcode formats that the library FIRVisionBarcodeFormatUnKnown = 0, should detect. FIRVisionBarcodeFormatAll = 0xFFFF, FIRVisionBarcodeFormatCode128 = 0x0001, FIRVisionBarcodeFormatCode39 = 0x0002, FIRVisionBarcodeFormatCode93 = 0x0004, FIRVisionBarcodeFormatCodaBar = 0x0008, FIRVisionBarcodeFormatDataMatrix = 0x0010, FIRVisionBarcodeFormatEAN13 = 0x0020, FIRVisionBarcodeFormatEAN8 = 0x0040, FIRVisionBarcodeFormatITF = 0x0080, FIRVisionBarcodeFormatQRCode = 0x0100, FIRVisionBarcodeFormatUPCA = 0x0200, FIRVisionBarcodeFormatUPCE = 0x0400, FIRVisionBarcodeFormatPDF417 = 0x0800, FIRVisionBarcodeFormatAztec = 0x1000, } NS_SWIFT_NAME(VisionBarcodeFormat) NS_SWIFT_NAME(VisionBarcodeFeature) @interface FIRVisionBarcodeFeature: NSObject A barcode detected in an image. typedef NS_ENUM(NSInteger, FIRVisionBarcodeValueType) This enum specifies a barcode's value format. For example, { TEXT, PRODUCT, URL, etc. FIRVisionBarcodeValueTypeUnknown, FIRVisionBarcodeValueTypeContactInfo, FIRVisionBarcodeValueTypeEmail, FIRVisionBarcodeValueTypeISBN NS_SWIFT_NAME(isbn), FIRVisionBarcodeValueTypePhone, FIRVisionBarcodeValueTypeProduct, FIRVisionBarcodeValueTypeSMS NS_SWIFT_NAME(sms), FIRVisionBarcodeValueTypeText, FIRVisionBarcodeValueTypeURL NS_SWIFT_NAME(url), FIRVisionBarcodeValueTypeWiFi NS_SWIFT_NAME(wifi), FIRVisionBarcodeValueTypeGeo, FIRVisionBarcodeValueTypeCalendarEvent, FIRVisionBarcodeValueTypeDriversLicense, } @property(nonatomic, readonly) CGRect frame The rectangle that holds the discovered feature relative to the detected image in the view coordinate system. @property(nonatomic, readonly, nullable) NSString Barcode value as it was encoded in the barcode. Structured *rawValue values are not parsed, for example: ‘MEBKM:TITLE:Google;URL:https://www.google.com;;’. @property(nonatomic, readonly, nullable) NSString Barcode value in a user-friendly format. May omit some of the *displayValue information encoded in the barcode. For example, in the case above the display_value might be ‘https://www.google.com’. If valueType==TEXT, this field will be equal to rawValue. This value may be multiline, for example, when line breaks are encoded into the original TEXT barcode value. May include the supplement value. @property(nonatomic, readonly) FIRVisionBarcodeFormat Barcode format; for example, EAN_13. Note that this field format may contain values not present in the current set of format constants. When mapping this value to something else, it is advisable to have a default/fallback case. @property(nonatomic, readonly) NSArray<NSValue *> The four corner points of the barcode, in clockwise order *cornerPoints starting with the top left relative to the defected image in the view coordinate system. These are CGPoints boxed in NSValues. Due to the possible perspective distortions, this is not necessarily a rectangle. @property(nonatomic, readonly) Format of the barcode value. For example, TEXT, PRODUCT, FIRVisionBarcodeValueType valueType URL, etc. Note that this field may contain values not present in the current set of value format constants. When mapping this value to something else, it is advisable to have a default/fallback case. @property(nonatomic, readonly, nullable) An email meessage from a ‘MAILTO:’ or similar QR Code FIRVisionBarcodeFeatureEmail *email type. This properly is only set if valueType is FIRVisionBarcodeValueTypeEmail. @property(nonatomic, readonly, nullable) A phone number from a ‘TEL:’ or similar QR Code type. This FIRVisionBarcodeFeaturePhone *phone property is only set if valueType is FIRVisionBarcodeValueTypePhone @property(nonatomic, readonly, nullable) A person's name, both formatted and as individual name FIRVisionBarcodeFeaturePersonName *personName components. @property(nonatomic, readonly, nullable) An SMS message from an ‘SMS:’ or similar QR Code type. FIRVisionBarcodeFeatureSMS *sms This property is only set if valueType iis FIRVisionBarcodeValueTypeSMS @property(nonatomic, readonly, nullable) A URL and title from a ‘MEBKM:’ or similar QR Code type. FIRVisionBarcodeFeatureURLBookmark *URL This property is only set iff valueType is FIRVisionBarcodeValueTypeURL @property(nonatomic, readonly, nullable) Wi-Fi network parameters from a ‘WIFI:’ or similar QR Code FIRVisionBarcodeFeatureWiFi *wifi type. This property is only set iff valueType is FIRVisionBarcodeValueType Wifi. @property(nonatomic, readonly, nullable) GPS coordinates from a ‘GEO:’ or similar QR Code type. This FIRVisionBarcodeFeatureGeoPoint *geoPoint property is only set iff valueType is FIRVisoinBarcodeValueTypeGeo @property(nonatomic, readonly, nullable) A person's or organization's business card. For example a FIRVisionBarcodeFeatureContactInfo *contactInfo VCARD. This property is only set iff valueType is FIRVisionBarcodeValueTypeContactInfo @property(nonatomic, readonly, nullable) A calendar event extracted from a QR Code. This property is FIRVisionBarcodeFeatureCalendarEvent *calendarEvent only set iff valueType is FIRVisionBarcodeValueTypeCalendarEvent @property(nonatomic, readonly, nullable) A driver license or ID card. This property is only set iff FIRVisionBarcodeFeatureDriverLicense *driverLicense valueType is FIRVisionrBarcodeValueTypeDriverLicense. Text Detection API NS_SWIFT_NAME(VisionTextFeature) @protocol FIRVisionTextFeature A class for text feature detected in an image. @property(nonatomic, readonly) CGRect frame The rectangle that holds the discovered feature relative to the detected image in the view coordinate system. @property(nonatomic, readonly) NSString Text contained in this feature, in string form. *recognizedText @property(nonatomic, readonly) NSArray<NSValue *> * The four corner points of the feature, in clockwise order starting cornerPoints with the top left relative to the detected image in the view coordinate system. These are CGPoints boxed in NSValues. NS_SWIFT_NAME(VisionTextBlockFeature) @interface FIRVisionTextBlockFeature: NSObject <FIRVisionTextFeature> A text block feature detected in an image. A text block is a simple list of “lines”. The contents of the text block, broken down into individual lines. @property(nonatomic, readonly) The contents of the text block, broken down into individual lines. NSArray<FIRVisionTextLineFeature *> *lines NS_SWIFT_NAME(VisionTextLineFeature) @interface FIRVisionTextLineFeature: NSObject <FIRVisionTextFeature> A text line feature detected in an image. @property(nonatomic, readonly) Text elements in this line. NSArray<FIRVisionTextElementFeature *> *elements NS_SWIFT_NAME(VisionTextElementFeature) @interface FIRVisionTextElementFeature: NSObject <FIRVisionTextFeature> A text element feature detected in an image. Interface methods definitions omitted. Does not introduce new methods on top of FIRVisionTextFeature. NS_SWIFT_NAME(VisionTextDetector) @interface FIRVisionTextDetector: NSObject A text detector that recognizes text and identifies text features in an image. typedef void ({circumflex over ( )}FIRVisionTextDetectionCallback)( The callback to invoke when the text detection NSArray<FIRVisionTextFeature *> * _Nullable features, completes. NSError * _Nullable error) NS_SWIFT_NAME(VisionTextDetectionCallback) − (void)detectInImage:(FIRVisionImage *)image Searches for text features in an image. The completion:(FIRVisionTextDetectionCallback)completion completion callback will be invoked on the main thread. 

What is claimed is:
 1. A mobile computing device, comprising: one or more processors; and one or more non-transitory computer-readable media that collectively store: a computer application; and a machine intelligence software development kit configured to: store one or more machine-learned models and a machine learning library; communicate with the computer application using an application programming interface to receive input data from the computer application; implement the one or more machine-learned models and machine learning library on-device to produce an inference based at least in part on the input data; and communicate with the computer application using the application programming interface to provide the inference to the computer application.
 2. The mobile computing device of claim 1, wherein the machine intelligence software development kit is included in and forms a part of the computer application.
 3. The mobile computing device of claim 2, wherein the one or more machine-learned models comprise one or more custom machine-learned models received by the mobile computing device from a cloud-based model training and storage system, the one or more custom machine-learned models having been trained by the cloud-based model training and storage system based at least in part on custom data associated with the computer application.
 4. The mobile computing device of claim 2, wherein the machine intelligence software development kit runs within an application process associated with the computer application.
 5. The mobile computing device of claim 2, wherein the machine intelligence software development kit is further configured to: without requiring a reinstallation of the computer application: receive an updated version of at least one of the one or more machine-learned models from a cloud-based storage system; replace an existing version of the at least one of the one or more machine-learned models with the updated version of the at least one of the one or more machine-learned models; and after replacing the existing version with the updated version, implement the updated version of the at least one of the one or more machine-learned models and the machine learning library on-device to produce at least one additional inference based at least in part on additional input data.
 6. The mobile computing device of claim 2, wherein the machine intelligence software development kit is configured to download the one or more machine-learned models at a runtime of the computer application.
 7. The mobile computing device of claim 1, wherein the machine intelligence software development kit is included in a first party support application that is separate from the computer application.
 8. The mobile computing device of claim 1, wherein the machine intelligence software development kit is configured perform on-device data logging and on-device model training.
 9. The mobile computing device of claim 8, wherein the machine intelligence software development kit is configured perform the on-device model training according to a set of customized scheduling rules associated with the computer application.
 10. The mobile computing device of claim 1, wherein the machine intelligence software development kit is configured perform on-device performance monitoring of the one or more machine-learned models.
 11. The mobile computing device of claim 1, wherein the machine intelligence software development kit is configured to implement a set of rules that specify whether inference occurs using the one or more machine-learned models stored in the machine intelligence software development kit or occurs using one or more cloud-based versions of the one or more machine-learned models stored in a cloud-based computing system.
 12. One or more non-transitory computer-readable media that collectively store: a computer application, wherein the computer application comprises a machine intelligence software development kit that is included in and forms a part on the computer application, and wherein the machine intelligence software development kit is configured to: communicate with the computer application using an application programming interface to receive input data from the computer application; implement one or more machine-learned models and machine learning library on-device to produce an inference based at least in part on the input data; and communicate with the computer application using the application programming interface to provide the inference to the computer application.
 13. The one or more non-transitory computer-readable media of claim 12, wherein the one or more machine-learned models comprise one or more custom machine-learned models received by the mobile computing device from a cloud-based model training and storage system, the one or more custom machine-learned models having been trained by the cloud-based model training and storage system based at least in part on custom data associated with the computer application.
 14. The one or more non-transitory computer-readable media of claim 12, wherein the one or more machine-learned models comprise one or more first party machine-learned models.
 15. The one or more non-transitory computer-readable media of claim 12, wherein the machine intelligence software development kit runs within an application process associated with the computer application.
 16. The one or more non-transitory computer-readable media of claim 12, wherein the machine intelligence software development kit is further configured to: without requiring a reinstallation of the computer application: receive an updated version of at least one of the one or more machine-learned models from a cloud-based storage system; replace an existing version of the at least one of the one or more machine-learned models with the updated version of the at least one of the one or more machine-learned models; and after replacing the existing version with the updated version, implement the updated version of the at least one of the one or more machine-learned models and the machine learning library on-device to produce at least one additional inference based at least in part on additional input data.
 17. The one or more non-transitory computer-readable media of claim 12, wherein the machine intelligence software development kit is configured to download the one or more machine-learned models at a runtime of the computer application.
 18. A computer-implemented method comprising: receiving, by a machine intelligence software development kit included in a computer application stored by a mobile computing device, input data from the computer application via an application programming interface; in response to receipt of the input data, causing, by the machine intelligence software development kit, implementation of one or more machine-learned models on the mobile computing device via a machine learning library to produce an inference based at least in part on the input data; and providing, by the machine intelligence software development kit, the inference to the computer application via the application programming interface.
 19. The computer-implemented method of claim 18, wherein causing, by the machine intelligence software development kit, implementation of the one or more machine-learned models on the mobile computing device via the machine learning library comprises implementing, by the machine intelligence software development kit, the one or more machine-learned models using the machine learning library.
 20. The computer-implemented method of claim 18, wherein causing, by the machine intelligence software development kit, implementation of the one or more machine-learned models on the mobile computing device via the machine learning library comprises performing, by the machine intelligence software development kit, a call to a first party support application that is separate from the computer application such that the first party support application implements the one or more machine-learned models using the machine learning library. 